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ABSTRACT 


Reliable multicast protocols provide a means to deliver data from one sender to 
many receivers with assurance. Reliable multicast is better suited than imicast for the 
bandwidth restricted, high error rate, hostile communications environment found in the 
military’s tactical arena. General purpose protocols ensure adaptability to the variety of 
communications suites currently used by the military. As well, any acceptable multicast 
protocol must support varying levels of assurance, from unreliable delivery to full 
reliability. 

This thesis evaluates the performance capabilities of one implementation of the 
Xpress Transport Protocol — SandiaXTP, which is a reliable multicast transport protocol. 
Four experiments are run on a testbed consisting of four Sun SPARC4 workstations. 
These experiments look at unicast and multicast transmissions with varying numbers of 
induced errors. The included performance measurements examine the various challenges 
present in a communications medium subject to attack. The results demonstrate that 
reliable multicast in a tactical environment is possible. 
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1. INTRODUCTION 


A. INTRODUCTION 

Data may be transferred from a host to multiple recipients by using either a 
multiple unicast or single multicast transmission. A unicast transfer of data may fulfill 
the needs of information exchange between receivers on an individual basis. However, in 
a military combat environment, there are numerous scenarios in which multiple receivers 
need data at the same time. It is under these operating conditions that a multicast protocol 
is most beneficial, facilitating the simultaneous dissemination of information to specific 
receivers within the network over a single connection. This thesis provides an analysis 
and evaluation of several existing US Naval communication methods, and examines the 
potential for adoption of reliable multicast within a tactical amphibious scenario. 

This chapter presents the differences between multicast and imicast 
communication. To clarify the issue of multicast and unicast, a brief description of both 
IS provided. This is followed by a description of the existing Navy communications 
technologies and descriptions of the various multicast protocols. A portrayal of the data 
transfer protocol stack follows, and then a discussion of the reliability issue. Finally, the 
advantages of multicast in a tactical environment is briefly described. 

B. UNICAST DATA TRANSFER 

A unicast packet is a packet addressed to a single node on the network. Each 
node has a unique address; packets are forwarded by routers until they arrive at the 
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destination. An IP address contains an encoding of the subnet, which assists the routing 
protocols. It is only those routers that are in the transmission path of the packet that will 
forward the packet. (Figure 1.1). 
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Figure 1.1 Example of Unicasting 


C. THE ISSUE OF BROADCASTING DATA 

A second method of data transfer is to broadcast the data. This entails each bridge 
or router forwarding the received packets on all interfaces with the exception of the path 
from which the packet was received. This is similar to a television broadcast, in that the 
signal will be retransmitted without regard to which receivers are interested in the data. 
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This results in the indiscriminate use of bandwidth, as ALL destinations will receive the 
packets which must traverse all data transmission routes, even if there are no destination 
addresses downstream (Figure 1.2). 



D. MULTICAST DATA TRANSFER 


A multicast packet is a packet addressed to a subset of nodes on the network. The 
group of nodes which share Ihe same multicast address comprises a multicast group. 
Bridges forward these multicast packets to the downstream interfaces (i.e., all segments 
“see” all packets). Data are delivered to each member of the multicast group. This 
transmission method necessitates that only a single copy of the information is sent by the 
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source, and the routers within the transmission path generate the required number of 

copies for delivery to all members of the multicast group. Multicast possesses several 
benefits over unicast, including: 

• A single transmission by the source is sent to numerous recipients; 

• More efficient use of bandwidth as transmission over any given route onlv 

occurs once; ^ 

• Concurrent receipt of data ; 

EiAanced mobility, since the destination multicast IP address is not tied to the 
subnet; 

• Routing is discovered by Multicast Backbone (MBONE) protocols; 

• Packets are only delivered to those interested. 


Reliable multicast suffers from two disadvantages: throughput is determined by the 
slowest receiver, and group management becomes more difficult as the number of 
receivers mcreases. A visual representation of multicasting is provided in Figure 1.3. 
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E. EXISTING NAVY TECHNOLOGY 


1. Ship To Shore Circuit Modes Of Operation 


There are three methods of ship to shore radio frequency circuit operation: 
duplex, simplex, and semi-duplex. Hardware and frequency availability dictate which 
method will be used. 
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«. Duplex 


A duplex circuit is designed to transmit and receive data simultaneously. 
The transmitting and receiving stations each utilize two frequencies: a station transmits 
on one frequency, and receives on the other. The advantage of this type of circuit is the 
time consideration: one frequency can be used for continuous data transfer while a 
second frequency can be utilized for packet acknowledgment. 

b. Simplex 

A simplex circuit consists of a single frequency on which is both 
transmitted and received. The least technologically advanced of the modes of operation, 
simplex circuits are normally reserved for UHF and those platforms that are not equipped 
with duplex equipment. 

c. Semi-duplex 

A semi-duplex circuit is a combination of duplex and simplex modes of 
operation, and is used primarily on task force/task group/ORESTES. With the exception 
of the Net Control Station (NECOS), all stations utilize simplex procedures. The NECOS 
transmits and is received on a second frequency, allowing for continuous transmission by 
the NECOS. 

2. Fleet Communications 

The highly dynamic operating environments characteristic of modem fleet units 
mandate the utilization of communications systems capable of providing high-speed, 
accurate, and secure two way data transfer. 
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Through equipment design and installation, many equipments are 
compatible with each other and can be used to accomplish various 
functions. Using this design concept, nearly all the communications needs 
of a ship can be met with fewer pieces of commimications equipment than 
were previously required. (NAVEDTRA 1994) 


The following is a brief description of these Naval assets. 


a. Ultra-High-Frequency (UHF) Systems 

The UHF band occupies the 300 MHz to 3 GHz band of the RF spectrum 
and is used for line-of-sight, short range communications. This means that the 
transmitting and receiving antennas must be physically visible to one another, and 
unaffected by the curvature of the earth. Since satellite communications are also line-of 
sight, the UHF band is utilized for both satellite uplink and downlink communications, 

effectively eliminating the possibility of direction finding in a hostile communications 
environment. 


b. Super-High-Frequency (SHF) Systems 

The SHF band of 3 to 30 GHz is used exclusively for line-of-sight 
communications, and primarily for satellite communications. “SHF satellite 
communications is a high-volume system that offers reliable tactical and strategic 
communications services to U.S. Navy elements ashore and afloat.” (NAVEDTRA 1994) 

c. CUDDCS 

The Common User Digital Information Exchange System (CUDIXS) 
provides a bi-directional, ship-to-shore-to-ship, high-speed digital data communications 
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link between a ship and a Naval Computer and Telecommunications Area Master Station 
(NCTAMS) or Navy Computers and Telecommunications Station 
(NAVCOMMTELSTA).” (NAVEDTRA 1994) A single Fleet Satellite Communications 
(FLTSATCOM) half-duplex channel provides a synchronous link between the CUDIXS 
shore station and the subscribers afloat. The system is limited to 60 subscribers; 10 
special subscribers and 50 primary subscribers. Special subscribers have the capability to 
transmit and receive data to and from CUDIXS; primary subscribers are allowed a “send 
only” capability. “The CUDIXS/NAVMACS (Naval Modular Automated 
Commimications System) combine to form a commimications network that is used to 
transmit general service (GENSER) message traffic between ships and shore 
installations.” (NAVEDTRA 1994) NAVMACS acts as the automated shipboard 
terminal for interfacing with shore based CUDIXS systems and the Fleet Broadcast 
System. While a satellite commimication circuit is an effective means of broadcasting 
and even multicasting data, CUDIXS is inappropriate for communications wi thin a 
tactical group due to the reliance on a NCTAMS or NAVCOMMSTA. Additionally, the 
relatively small number of stations given the capability to transmit and receive data — ten 
- limits the overall functionality of CUDIXS. 

d. TADIXS (Tactical Data Information Exchange System) 

TADIXS is a direct communications link between command 
centers ashore and afloat. TADIXS provides one-way transmission 
of data link communications. (NAVEDTRA 1994) 

Unfortunately, the one-way TADIXS link does not fulfill the need for a reliable means of 

data transfer. Additionally, the exclusion of any units other than command level 


8 



mandates a hierarchical information transfer procedure, resulting in time delays in 
delivering vital information to the operating forces. These delays could be the critical 
moments that differentiate between success and failure in a mili tary operation. 


e. Fleet Broadcasts 


Fleet broadcasts are the primary means by which mobile imits receive 
messages. The method by which these transmissions are made has been termed the Fleet 
Multichannel Broadcast System (MULCAST). Also known as the “November System,” 
the highly flexible MULCAST system provides global service to the fleet via one of the 
four major NAVCOMMAREAs. (NAVEDTRA 1994) The areas of coverage are shown 
in Figure 1.4, including their NCTAMS (in Guam, Honolulu, Norfolk, and Naples, Italy). 



Figure 1.4 Naval Communications Areas (from NAVEDTRA Radioman Communications, 1994) 
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Each of the four NAVCOMMAREAs is controlled by a NCTAMS which 
supervises the coordination of the fleet broadcast and all other communication circuits 
assigned to that area. To receive MULCAST transmissions, which encompass 16 
separate information channels, ships are assigned to copy specific channels, dependent 
upon ship type and similarity of mission. Further, ships are assigned to copy a channel 
for specifically addressed traffic and a channel for general traffic. 

To ensure traffic continuity, each message broadcast via MULCAST is assigned 
an alphanumeric Broadcast Sequence Number (BCSN). To verify that all messages 
addressed to one s ship have been received, ships guarding the broadcast must maintain a 
file by BCSN listing all broadcast numbers transmitted. Additionally, once an hour on 
the hour, a message summary (RECAP) is transmitted which provides a summary of the 
traffic transmitted during the previous hour. The RECAP details the BCSN, precedence, 
date-time group (DTG), originator, and broadcast addressees for each message 
transmitted. If a ship did not receive a message for which it was addressed, it must 
request a retransmission of that message, or obtain a copy from a ship in company. 

MULCAST is also inappropriate for tactical group communications as all 
transmissions must originate at a NCTAMS. Further, MULCAST is a non-reliable 
system: message receipt verification is accomplished via the RECAP, a serious detraction 
to the smooth flow of data, and a possible contributor to battlefield communications 
confusion. 

f. NTDS 

The Naval Tactical Data System (NTDS) is a practical approach to 
ensuring the most effective use of both decision time and full fleet 
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capability. Integrated design and major components of the NTDS 
provide the fleet with automated data handling capability 
(NAVEDTRA 1993) 

In an operational environment, the computer-controlkd NTDS coordinates 
the collection of data from the ship’s sensors and from external sources via 
communications links. Inputs to the system include radar, sonar, navigation systems, 
electronic warfare, fire control, and manual inputs from keysets. As an output, NTDS 
provides a single display of air, surface, and subsurface contacts (and their threat 
evaluations), contact course and speed, weapons assignments, as well as land masses and 
the ability to determine bearing and range to any point within the display. There are four 
major subsystems within the NTDS system: 

• Link 11: Link 11 provides high-speed computer-to-computer transfer of tactical 
environment information, command orders, and participating unit status to all 
other tactical data systems with a nominal range of 300 miles. Link IT uses 
groups of participating imits and a standard message format for the exchange of 
digital information among land-based, shipbome, and airborne platforms. 
Although primarily utilizing the HF and UHF bands. Link 11 may also be 
operated by Limited Range Intercept Satellite Commimications (LRI 
SATCOM), but this increased advantage is offset by imposed restrictions, as 
system architecture mandates the use of a task force aircraft and limits Link Hgta 
transmissions to one channel, along with two channels for voice 
communications. In addition, the Link 11 system is based on obsolete 
equipment that has been in use for over twenty years, and is not portable to 
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current technology. However, due to its high level of functionality. Link 11 is 
the preferred mode of tactical data transfer between operating units. 

The scene of operations from a radar point of view is expanded by 
infusing data received from other Link 11 ships onto one plot. The infusion is 
synchronized via computer based on the position (latitude and longitude) of 
one’s own ship, and the position of the other ships linking data. Unfortunately, 
errors are introduced by the unavoidable degradation of operating programs. 
Additionally, the plot is usually placed onto a paper trace by m amifll means. 
This plot acciunulates errors resulting from not only incorrect source data as 
described above, but also plotting gear inconsistencies and human error. 

• Link 14: Link 14 provides a means of transmitting track information, identity, 
engagement status, drop track reports, and gridlock information to ships not 
capable of participating in the Link 11 net. This system allows for the 
transmission of data via voice and teletype communications to those units not 
equipped with the more expensive, combat operations related hardware that 
makes up the Link 11 network. The data received must then be plotted 
manually, with the inherent flaws of the paper trace as detailed in the 
description of Link 11. 

• Link 4A: 

Link 4A enables an operational program to take control of the autopilot 
in a suitable equipped aircraft to control landing and takeoff, to pursue, 
or to follow collision intercept geometry. It can control a flight to the 
strike area and return it to the base without requiring pilot action. 
(NAVEDTRA 1993) 
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The level of control provided by the Link 4A system is at the discretion 
of the pilot, who can opt for fully automatic operation, use of the visual display 
(only), or totally disregard the system. This system is very useful in relaying 
geographic and contact data to aircraft. 

• Link 16: Link 16 is basically the same as Link 11, with the inclusion of a 
merged message format which allows for interservice and NATO link 
operations. Yet Link 16 faces the same limitations as Link 11, and can be 
further hampered by US forces infusing data from forei gn forces which 
periodically rely on sensors of inferior accuracy. 

g. SATCOM Systems 

“Satellite communication systems satisfy many military communications 
requirements with reliable, high-capacity, secure, and cost-effective telecommunications.” 
(NAVEDTRA 1994) While allowing for worldwide coverage (with the exception of 
those areas above 70°) including imderway platforms, satellite systems also provide an 
alternative to large, fixed land-based systems. There are two types of satellite 
communication systems: active and passive. An active satellite receives an uplinked 
signal, amplifies the signal, and then retransmits the signal back to earth (downlink). A 
passive satellite simply acts as a reflector (or “bent pipe”), physically redirecting the 
uplinked signal back to the surface of the earth. A basic satellite system (with various 
types of transceivers) is shown in Figure 1.5. 
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Figure 1.5 Satellite Communications Systems (from NAVEDTRA Radioman Communications 
1994) 


A satellite communications system is ideal for a tactical assault scenario 
since the satellite is not susceptible to localized attack. With a transceiver operated by 
each of the members of a multicast group, communications delivery and receipt (at each 
of those locations) is primarily dependent upon the satisfactory operation of local routers 
and the transceivers themselves. The combination of a satellite communications system 
and reliable multicast provides greater overall communications efficiency while keeping 
transmission errors to a minimum. Therefore, multicast communications wi thin the 
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scenario presented in the following chapter are the central focus of this thesis, with an 
emphasis on the conduct of experiments which vary factors such as: 

• Unicast or multicast transmission 

• Number of multicast group members 

• Inclusion of induced packet transfer errors 


F. THESIS ORGANIZATION 

This thesis is targeted for techmcal and non-technical readers. A short description 
of each chapter of this thesis is provided below as an overview: 


1. Chapter Descriptions 

• CHAPTER I — INTRODUCTION — Contains an overview of data 
communications technology, existing Navy communications technology, 
and the reasons for adoption of a new multicast system. 

• CHAPTER II — PROBLEM STATEMENT — Describes the tactical 
scenario in which the multicast system is to be implemented. A proposed 
solution is presented, along with descriptions of existing multicast 
protocols and the decision to use Xpress Transport Protocol (XTP). Also 
included is a list of related work. 

• CHAPTER III - EXPERIMENTATION ENVIRONMENT - A 
description of the sunulation environment is presented, including die 
“ships to chips” paradigm, and the identification of those pieces of 
hardware to be utilized during the multicast transmission experiments. 

• CHAPTER IV - EXPERIMENTS - A description of the various 
experiments to test the feasibility of amphibious scenario multicast. 
Experiments include unicast, multicast, increasing the number of multicast 
receivers, and the inclusion of packet errors. Detailed analysis of the 
experiments described in Chapter III. Both visual and technical analysis 
will be presented. 
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• CHAPTER V - CONCLUSIONS AND RECOMMENDATIONS - A 
summaiy of the importance of military multicast, and its potential for 
increasing tactical awareness. Finally, guidance on possible future 
expansion of the included research is presented. 

2. How to Use this Thesis 

Because there are both military and civilian entities involved in the acquisition of 
military hardware and software systems, recommendations on how to use this thesis for 
both types of employment are listed below: 

cu Operational Forces 

These individuals include assault team communications persoimel, CIC 
persormel, ship commanding officers, amphibious group commanders, fleet commanders, 
and fleet CINCs. The key players in any combat operation, it is these individuals who 
evaluate the current systems and provide recommendations for improvements or 
replacements. This thesis demonstrates the need for a tactical scenario multicast system, 
and provides one answer to the question “What system should we adopt?” 

b. Program Management 

These individuals include members of the government who provide 
funding for systems research and acquisition, and the private contractors who develop the 
requested systems. For these persons, this thesis provides a feasibility study into the 
potential use of a multicast system for close-in amphibious operations. Additionally, 
analysis is provided of the potential benefits to be gained from the adoption of that 
system. 
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II. PROBLEM STATEMENT 


A. INTRODUCTION 

The US Navy has been using multicast transmission for audio and video 
applications. Until now, technology did not support the reliable transfer of multicast data, 
nor was this necessaiy: the loss of a few bits or packets in audio/visual data transfer 
yields a negligible impact for those applications. However, now the technology exists to 
support reliable multicast data transfer, and the Navy should incorporate its use in the 
tactical environment. Developments in the speed of CPU’s, establishment of the IP 
Multicast Backbone (MBONE) on the Internet, and the rapid growth in the number of 
users of Internet-style communications systems have all contributed to the need to reliably 
transfer large amounts of data to multiple addresses simultaneously. Experimental 
protocols exist that possess the potential to solve the reliable multicast problem. These 
will be discussed later in this chapter. 

There are several scenarios in which the military could benefit fi-om multicast data 
transmission of battlefield images and text. It is the intent of this chapter to provide one 
such basic scenario: an amphibious beach landing and the subsequent periodic transfer of 
landing zone conditions. The communications that occur between the ships and the 
tactical commanders on those ships is not the direction of this study; instead, this scenario 
is intended to motivate reliable the multicast transfer of information between the Naval 
Beach Group Element (ashore) and the ships at sea. This scenario will serve as the basis 
for the multicast experiments described in Chapter IV. To support those experiments, an 
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analysis of existing multicast protocols is included, and the choice of which protocol best 
supports the Navy’s needs is tendered. 

B. AMPHIBIOUS READY GROUP SCENARIO 

Reliable multicast could be applied to many military scenarios, but this thesis 
focuses on one tactical application - the Amphibious Ready Group (ARG). The ship 
types and command structure that comprise an ARG may vary slightly, but the general 
composition remains the same. 

Tactical orders are normally received by the Joint Task Force Commander 
onboard an aircraft carrier (CVN) which can be located hundreds of miles away. Orders 
are then passed to the Commander Amphibious Task Force (CATF) embarked aboard the 
senior vessel in the ARG, normally an Amphibious Assault Ship (LHD, LPD or LPH). 
Additionally, the ARG normally contains one Amphibious Transport Dock (LPD) and 
one or two Dock Landing Ships (LSD). Finally, an Assault Craft Unit consisting of three 
Landing Craft, Air Cushion vehicles (LCAC) will be carried by each LSD. These LCAC 
are used for high speed transfer of troops, equipment and cargo from the ships to 
designated areas ashore. There are other elements that round out the entire ARG 
composition; however, it is the new technology and capability introduced by the LCAC 
that brings forth one need for reliable multicasting within the Navy. 

The Chain of Command involves the ARG Commander (CATF), Commanding 
Officers of the ARG ships, and the following embarked units stationed aboard the 
Amphibious Assault Ship: 
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• Commander of the Marine Expeditionary Unit (MEU), responsible for further 
dissemination of orders to the Marine Corps units on the LPDs and the LSD. 
This is the same person that assumes the role of CLF during the actual assault. 

• The Tactical Air Commander. 


• Commanding Officers of embarked squadrons and other Marine Corps and 
Navy elements that might be temporarily stationed aboard the assault ship. 

Aboard the LSD, orders are passed to the Officer in Charge of the LCAC 
detachment. Aboard the LPD, orders are passed to the Air Detachment and the Naval 
Beach Group - the team of naval personnel that establish a foothold on the beach and 
transmit back to the ARG the beach, surf and weather conditions. A summary of the 
Chain of Command and the vessels involved is shown in Figure 2.1. 
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Figure 2.1 Amphibious Assault Scenario 
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C. PROTOCOL REQUIREMENTS FOR THE SCENARIO 


There are many features in next generation transport protocols that are useful for 
communications between fleet units. However, it is important to narrow the field to a 
critical few that would be realistic to accomplish. As a result, this thesis will focus on 
several key attributes that are considered to be the basic features for a successful 
migration to a military environment. 

First, it is imperative that any adopted protocol remain focused at the transport 
layer and not the application layer. Remaining focused at the transport layer means that 
the protocol can remain flexible and be easily adapted to varying communications 
requirements. 

Second is the consideration of “total ordering” or “source ordering” of packets. 
Total ordering facilitates a causal relationship between the messages in the multicast 
group (i.e., if one message causes another message to be sent, the two messages are seen 
by a third entity in that order, and not the opposite order). This assumes multiple 
transmitters. (Strayer, 5 March 97 email to Johnstone) Even though total ordering has 
application in military communications, normally only one transmitter will act as the 
central point for multicast transmission generation. In this set of circumstances, source 
ordering is preferred, in which the sole transmitter places outgoing messages in the proper 
order. The class of applications presented by the scenario. will only require source 
ordering. 
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Lastly, not all information that is sent in a tactical environment has a need to be 
delivered reliably; therefore the protocol must be able to support various transmission 
options (e.g., unicast, unreliable multicast and reliable multicast). These attributes will 
serve as a basis for protocol selection for forthcoming experiments. 

D. THE OSI MODEL 

In order to make an informed decision of which multicast protocol best suits the 
requirements of the scenario, it is necessary to imderstand the Open Systems 
Interconnection (OSI) reference model. In response to the impending inevitable 
proliferation of proprietary systems and dieir incompatibility witii each other, the 
International Organization for Standardization (ISO) established a subcommittee in 1977 
to develop an architecture that would define the communication tasks that define the 
ability of computers to exchange information. The result was the OSI reference model, 
adopted in 1983, which is a framework for defining standards for linking heterogeneous 
computers. The model is shown in Figure 2.2. 
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Figure 2.2 The OSI reference model 


1. OSI Model Layers 

The physical layer is concerned with the transmission of an unstructured bit 
stream over a physical communications medium. It deals with the mechanical, electrical, 
functional and procedural characteristics to access that medium. This layer covers the 
physical interface between devices and the rules by which bits are passed from one device 
to another. The data link layer “provides for the reliable transfer of information across 
the physical link; it sends blocks of data (frames) with the necessary synchronization, 
error control and flow control.” (Stallings, 1994) Since the physical layer provides a 
means of transferring bits (only), the data link layer is needed to frame the bits into 
packets, provide some error detection, provide the means to activate, maintain, and 
deactivate the link. 
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The end-to-end service is provided by the network, transport, and session layers. 
The network layer “provides upper layers with independence from data transmission and 
switching technologies used to connect systems; responsible for establishing, 
maintaining, and terminating connections.” (Stallings, 1994) It provides the routing and 
relaying of network data units across multiple network segments and multiple networks. 
The transport layer “provides reliable, transparent transfer of data between end points; 
provides end-to-end error recovery and flow control.” (Stallings, 1994) This layer 
provides a reliable mechanism for the exchange of data between processes in different 
end-systems by ensuring that the data units are delivered error-free, in the proper 
sequence, with no losses or duplications. The purpose of the session layer is to provide 
the means for organizing, synchronizing, and managing dialogues between end-nodes. 
The key services provided by the session layer include dialogue discipline (full duplex, 
half-duplex, etc.), groupings of data, and the ability to recover data if there is a failure 
between predetermined checIq)oints within the data stream. 

The user-oriented portion of the model consists of the presentation layer and the 
application layer. The presentation layer “provides independence to the application 
processes from differences in data representation (syntax).” (Stallings, 1994) The 
application layer “provides access to the OSI environment for users and also provides 
distributed information services.” (Stallings, 1994) This layer contains management 
functions and other mechanisms to support distributed applications, such as file transfer 
and electronic mail. 
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The focus of this thesis is to demonstrate the benefits of adopting a reliable 
multicast protocol for data transmission. Doing so mandates a closer look at the transport 
layer, where a multicast protocol undertakes its mission. 

2. The Transport Layer: A Closer Look 

As discussed above, the transport layer provides for a reliable exchange of data 
between processes by ensuring that the data is transferred without errors, properly 
ordered, and without duplication. The transport layer may also be concerned with 
optimizing the use of network services and providing a requested quality of service to 
session entities, such as acceptable error rates, maximum timing delay, packet priority, 
and message security. Essentially, the transport layer serves as the user’s liaison with the 
communications facility. (Stallings, 1994) “In many ways, the scenario that places the 
greatest responsibility on the transport layer protocol is that of providing end-to-end 
reliable data delivery over an unreliable underlying network layer service.” (Strayer, 
Dempsey, Weaver, 1992) 

3. Reliable Multicast in the OSl Model 

The OSI model can be summarized and related to this thesis by sectioning the 
model into four parts, as shown in Figure 2.3. The highest section of the model. 
Applications, adds no value to the integrity or reliability of the bit stream, and exists 
solely to enable the transfer of data via requests to the XTP daemon. The next highest 
section of the model consists of a reliable multicast protocol, many of which are 
discussed in the following section. This protocol will be required to perform end-to-end 
error recovery and flow control. The next section consists of the Network Layer and for 
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purposes of this thesis, will be the IP Multicast Backbone (MBONE) which was created 
to allow for the multicast transfer of data across the Internet. Finally, the Media layer is 
the collection of physical and datalink protocols (often packaged together, like Ethernet 
and FDDI) that provide the network infrastructure to deliver the multicast packets to the 
intended receivers. 


Applications 

Reliable 

Multicast 

Protocol 

MBONE 


Media 

Layer 

Figiffe 2.3 Abbreviated OSI Model 

With an understanding of how the OSI Model functions to facilitate the transfer of 
data from one platform to other platforms, the question is now raised of which protocol 
should be used to fill the “Reliable Multicast Protocol” block in Figure 2.3. The 
following section provides a brief description of the most advanced multicast protocols, 
and briefly describes the advantages and disadvantages of each. This information is then 
used to make a decision of which protocol best suits the needs of the scenario. 
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E. RELIABLE MULTICAST PROTOCOLS 


1. DeHnition of Reliability 

As a precursor to discussing reliable multicast protocols, the term “reliable” needs 
clarification. Unlike the dictionaiy definition; “That can be relied upon: 
DEPENDABLE” (Webster’s, 1996), the most comprehensive definition of reliability 
within the multicasting environment refers to three properties of a protocol, as described 
by Garcia-Molina and Spauster (1991). The first property is the length of time required to 
deliver a multicast message. The second property is termed “atomicity” and refers to all 
group members being required to deliver a reply to the initiating application within a 
specified time interval. The final property is ordering and covers the range from no 
requirement for specific priority addressing to members of the multicast group, to full 
delivery guarantees. These guarantees may persist regardless of remote host failures or 
operations within a hostile commimications environment. 

The most advanced multicast protocols in use today that should be considered are 
the Reliable Multicast Protocol (RMP), the Reliable Multicast Transport Protocol 
(RMTP), the Reliable Adaptive Multicast Protocol (RAMP), the Multicast Transport 
Protocol (MTP-2), and the Xpress Transport Protocol (XTP) (Bradner and Mankin, 
1996). Each of these transport protocols are considered to be mature and have been 
implemented to certain levels on various platforms (Petitt, 1996). However, there are 
marked differences in how each accomplishes the task of assured multicast delivery of 
data. 
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2. 


Reliable Multicast Protocol (RMP) 


RMP is based on the “Post-Ordering Rotating Token” model in which a token is 
rotated among group members and messages are ordered by the token site after they have 
been sent. (Montgomery, 1994) A token list is maintained by all members of the group 
and is updated upon the arrival or departure of group members. Advantages of RMP 
include: 

• Ability to vary Quality of Service from unreliable to totally resilient on a per 
packet basis; 

• Hosts limited to unicast capability may participate; 

• The rotating token distributes processing load among group members; 

• Ability to reconstruct the token ring following a network failure. 

However, RMP is hampered by its high overhead, as both messages and 
acknowledgments are multicast, as are NACKs and repairs (Petitt, 1996). Packets 
associated with administrative ftinctions such as joining and leaving the group are also 
multicast, further restricting the scalability of RMP. Finally, RMP is mainly meant for 
high-availability systems under a somewhat controlled internetwork, such as metropolitan 
area networks (MANs) and corporate intranets (Montgomery, 21 Aug 96 email to Petitt). 
The flow control mechanism utilized by RMP severely degrades performance of the 
protocol under conditions of moderate packet loss, and is the primary reason why the 
protocol is restricted to low loss environments. Some experience with RMP has shown 
that its performance suffers over a WAN (Petitt, 1996). 
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3. 


Reliable Multicast Transport Protocol (RMTP) 


“RMTP provides sequenced, lossless delivery of bulk data from one sender to a 
group of receivers.” (Lin, 1996) The objective of RMTP is to “...guarantee complete 
reliability at the expense of delay” for applications hosted on a wide area network (Lin, 
1996). The multicast delivery tree of RMTP is rooted at a sender; subfrees begin at 
special receivers called Designated Receivers (DRs) or Acknowledgment Processors 
(APs). These DRs are responsible for reliably delivering data to their subtrees (Petitt, 
1996). 

RMTP is well suited for the reliable delivery of bulk data in a non-delay important 
environment RMTP differs from RMP in that RMTP is a single transmitter system, it 
localizes ACKs and NACKs, and it sends repairs either unicast or multicast, thus saving 
bandwidth. 


4. Reliable Adaptive Multicast Protocol (RAMP) 

RAMP was designed for collaborative-interactive applications hosted on “...all- 
optical, circuit-switched, gigabit...” networks. (Koifinan, 1996) However, “...RAMP’s 
design is also relevant for the next generation of packet switched networks.” (Koifinan, 
1996) There are two modes of operation for the RAMP protocol: Burst Mode and Idle 
Mode. 


a. Burst Mode 

A burst of data is a series of packets which follow each other within some 
specified interval, this is true for both the Burst Mode and the Idle Mode. When the time 
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between two consecutive packets exceeds this interval, the first packet marks the end of a 
burst while the second packet marks the beginning of the next burst (Koifinan, 1996). 

Burst Mode is intended to be used during times of high data transfer. The 
beginning of each burst is marked by a data packet with an ACK flag set. Upon 
completion of the burst, a single Idle message is sent to signify that the sender resides in a 
silent status until the beginning of the next burst. Receivers that have chosen to guarantee 
reliability must respond to the sender’s ACK flag by returning the sequence number of 
the data packet which has the ACK flag set (Petitt, 1996). If the sender does not receive 
an ACK from the receiver, it retransmits the data. If no response is received after several 
retransmissions, the sender closes its control channel to the failed receiver (Koifinan, 
1996). 

b. Idle Mode 

Idle Mode is intended to be used in times of little data transfer. In this 
mode, there is no ACK flag set in the first data packet of a burst, nor is there a single Idle 
message transmitted after the last data packet in the burst. Instead, a series of Idle 
messages is multicast between bursts, each within a fixed time interval. If the time 
constraint of this interval is exceeded and neither a data packet nor Idle message is 
received, the receiver(s) unicast a Respond message to the sender. If the sender fails to 
respond to this message, the channel between the receiver and die (non-functional) sender 
is closed. In a similar manner, the continued connectivity to receivers is verified by 
periodic transmission of Idle messages by the receivers. If an Idle message from a 
receiver is lost, the sender closes the channel to that receiver. (Koifinan, 1996) 
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The receiver is responsible for detecting and acting on failed connections 
in Idle Mode. Although the periodic Idle messages consume more bandwidth than the 
protocol overhead of the Burst Mode, they relieve the sender of the burden of process ing 
acknowledgments (Koifinan, 1996). 

5. Multicast Transport Protocol (MTP-2) 

MTP-2 is based on the concept of one multicast “master” and many producers and 
consumers. The master controls all aspects of group communications (Braudes, 1993). 
Packet transmission in MTP-2 is contingent upon possession of a token. To obtain a 
token, a producer transmits a unicast request to the master. The approved request spawns 
a serialized approval response (message number). A producer in possession of a message 
number then marks all packets of the message for which the approval was granted and 
multicasts the packets. The token is implicitly returned to the master with the final packet 
of the message. 

There are many advantages of MTP-2, the first of which is minimal overhead. For 
each message sent, the protocol adds a unicast token request and confirm packet. 
However, for one-to-many multicasting, the master can be migrated to the producer to 
eliminate this overhead. (Petitt, 1996) Also, migration of the master from one machine 
to anodier is relatively simple: any suspected loss of the master is verified by receivers 
sending it a special packet. If the master does not respond, the members assume that it 
has failed and elect a new master. The new master then “...accumulates information 
about the status of all active messages ... from ... all responding ... members.” 
(Bormann, 1994) Additionally, MTP-2 defines a dedicated unicast channel for each 
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producer-consumer pair. Lastly, prioritization can be enacted for both token requests and 
messages. 

MTP-2 relies on a receiver-initiated/sender-oriented error recovery method that 
severely restricts scalability. Although unicast NACKs consume less bandwidth than 
multicast NACKs, retransmission requests for missing packets may be made by multiple 
receivers, leading to multiple retransmissions of the same packet(s). Another concern 
within the military application is the limit of the number of messages that can be pending; 
12. (Bormann, 1994) Lastly, MTP-2 caimot guarantee full reliability. The producers of 
data transmit the packets and then, after a retention period has elapsed, discard the dat a 

If a NACK is received after this time has passed, no retransmission is possible. (Petitt, 
1996) 


6. The Xpress Transport Protocol (XTP) 

The Xpress Transport Protocol is a high-performance transport protocol designed 
to meet the needs of distributed, real-time, and multimedia systems in both unicast and 
multicast environments.” (Atwood, 1996) Moreover, it is designed to provide a wide 
range of communication services built on the concept that orthogonal protocol 
mechanisms can be combined to produce appropriate paradigms within the same basic 
framework (Strayer, 1996). An orthogonal approach allows specific functions to be 
operated independently of other functions (e.g., error control activation and deactivation 
does not have an effect on other fimctions, such as flow control). Additionally, XTP is 
“transmitter driven”: receivers that are a part of the group are controlled by the 
transmitter and respond as directed. Therefore, “XTP appears to be the most mature of 
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the protocols presented for consideration” (Petitt, 1996). A closer look at the XTP 
specification reveals additional benefits, described below. 

a. General Approach 

The major advantage that XTP can offer the Navy is that of a general 
pmpose protocol with the potential of providing all the communication protocol needs, 
such as reliable datagrams, unreliable datagrams and reliable multicast connections, 
required in a tactical environment. Another important consideration is that the XTP 
specification is not restrictive. There is no specific requirement for data to have one 
particular structure PCTP Forum, 1995). This allows for adaptability to various 
commimications needs found in a complex commimications theater. Additionally, XTP is 
efficient in its error handling and flow control, thereby supporting a dynamic 
infrastructure. XTP takes a general purpose approach that departs from the trend of most 
multicast protocols today. The majority of these protocols focus on application layer 
framing, while XTP remains focused at the transport layer to provide general services to 
all applications (Buddenberg, 1997). This general purpose approach is very attractive 
because it provides greater flexibility and support for different levels of group reliability 
and may specify that only certain receivers within a group be fully reliable (Petitt, 1996). 

b. Group Management 

XTP employs a group management technique which is an aggregation of 
the information from each of the receivers that belong to the multicast group. This 
capability is important in order to manage the membership status of the group. This 
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management includes the creation and deletion of group members, monito ring of 
members joining and leaving the group, and whether or not a member is actively 
responding (Strayer, Dempsey, Weaver, 1992). This group management also allows for 
“late joining” which allows group members to join and leave an established group during 
actual data transmission without interrupting the flow of that data. The late member will 
receive data commencing at the time of the join, and will not be sent previously 
transmitted data. 

F. SUMMARY 

With the rapid expansion in the use of distributed computing services both ashore 
and afloat, the Navy must continually seek new and better ways to employ emerging 
technologies, thus ensuring all assets are fully utilized. The use of multicast, and more 
specifically, the use of reliable multicast in the tactical environment can help during high 
traffic periods typical of crisis situations. Reliable multicast can be utilized to transmit 
any information where assured delivery is critical. The Navy needs to pursue a general 
purpose multicast protocol that is flexible enough to handle both traffic that requires 
reliability and traffic that does not require reliability. In attempting to determine which 
available reliable multicast protocol the Navy should adopt as a standard, it appears that 
the Xpress Transport Protocol possesses the attributes necessary to fulfill all of the 
demanding needs of the Navy. Specifically: 

• Transportation layer focus 

• Source ordering 
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• Ability for unicast, multicast, reliable, and unreliable transmission 
It is for this reason the authors have chosen to use XTP as the protocol for 
evaluating reliable multicast performance over unicast performance. - 
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in. EXPERIMENTATION ENVIRONMENT 


A. INTRODUCTION 

A testbed was created to analyze the performance capabilities of XTP 4.0. The 
testbed supports current experimentation objectives while allowing for continued 
expansion and scalability as more in-depth testing of reliable multicast protocols becomes 
possible. The Sandia National Laboratories implementation of XTP 4.0 was chosen 
based on the implementation’s ease of use, built-in performance tracking mechanisms, 
immediate availability, and easy accessibility to support information. 

B. TESTBED HARDWARE 

The testbed was built using existing hardware available in one of Naval 
Postgraduate School’s laboratories. In particular, four identical Sun SPARC4 
workstations running Solaris 4.0 were used, attached via ethemet to the main campus 
network that provided access to the Internet, as depicted in Figure 3.1. These four 
machines each represent a main receiver or transmitter from each of the ARG ships 
presented in the scenario from Chapter II. The Sun workstations were chosen primarily 
because they have built in support for multicast IP. Equally important was the ability to 
demonstrate that reliable multicast could be implemented on standard machines without 
significant upgrade. This is critical in the military arena where upgrades and equipment 
acquisition can sometimes be difficult. The selected software package also supports 
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several PC-based operating systems. Testing on those platforms was beyond the scope of 
this thesis, but provides opportunity for follow-on research and project expansion. 



Figure 3.1 Experiment Testbed 


C. SOFTWARE IMPLEMENTATION 

1. Rationale for Selection of SandiaXTP 

SandiaXTP, the Sandia National Laboratories implementation of XTP 4.0 
(SandiaXTP website, 1995) was designed to provide a vehicle for research into the 
further development and advancement of the XTP 4.0 specification. As a result, 
SandiaXTP contains the latest changes to the specification agreed upon by the XTP 
Forum. Consequently, updates to the SandiaXTP implementation were frequent, and the 
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test platform was continually updated with the latest available releases. The biggest g ain 
realized by the SandiaXTP implementation of XTP 4.0 is its flexibility and platform 
adaptability. For a list of currently supported platforms, see Figure 3.2. 

=> SGI workstations miming IRIX 4.x and 5.x 

=> Sun workstations mnning SunOS 4.x and SunOS 5.x (Solaris) 

=> DECstation 5000 running Ultrix 4.x 
^ DEC Alpha workstations runnmg OSF/1 

HP workstations running HP-UX 9.x (but not with CC compiler) 

=> 1386 PCs running BSDI/OS 2.x 
=> 1386 PCs running FreeBSD 2.x 

=> IBM RS/6000 workstations runnmg AIX (but not with xlC compiler) 


Figure 3.2 SandiaXTP Platform Compatibility List 
From SandiaXTP User’s Guide 

2. Meta-Transport Library 

The Meta-Transport Library (MTL) (MTL website, 1995) is a set of C-t-+ base 
classes that serve as a basis for building transport protocols. SandiaXTP is built on MTL. 
While maintaining efficiency, MTL has been designed to be portable, adaptable, 
configurable and readable. The goal of MTL is to allow the rapid deployment and 
prototyping of a protocol implementation without the need for kernel modifications. 
Protocols are created from MTL simply by extending the base classes with specific 
protocol algorithms. Protocols based on MTL are implemented as user-space daemons 
(see Figure 3.3), which means code maintenance, debugging and customization are all 
easier since these activities do not require root access of kernel reconfiguration. 
Additionally, by being in the user-space, the need for root access to use the daemon is 
limited to changes in the daemon status (e.g., starting, stopping and checking the status of 
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the daemon). This increases daemon availability to a greater range of users and sets the 
stage for portability to platforms running non-UNIX operating systems. (MTL User’s 
Guide, 1997) 



Figure 3.3 MTL User/Daemon Model 
From Meta-Transport Library User’s Guide 


3. SandiaXTP 

SandiaXTP is an MTL-based implementation of XTP 4.0. Since SandiaXTP is 
derived from MTL, SandiaXTP is a user space daemon where a user’s applications make 
requests of the daemon, and the daemon satisfies them. 

SandiaXTP exposes to the user the built-in protocol options that allow for the 
applications to create individual paradigms, such as unreliable datagrams and reliable 
datagrams, with error control, flow control and rate control based on the communication 
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need. This means that the degree to which reliability is maintained rests solely with the 
user. This feature is particularly important in military applications where not all 
information would have the need to be transferred via reliable means. (SandiaXTP User’s 
Guide, 1997) 

4. Software Installation 

The installation of MTL and SandiaXTP are both easy and straight forward. The 
user guide has detailed information to guide the user through the installation process. 
Since SandiaXTP relies on MTL base classes for its daemon services, MTL must be 
installed prior to SandiaXTP. Both software packages are available via anonymous FTP 
from ftp://dancer.ca.sandia.gov” The user guide recommends that either the AT&T 
cfront compiler (CC) or the GNU C-h- compiler be used. The latter is available via FTP 
from fip://prep.ai.mit.edu/pub/gnu.” Both were used to install the software packages on 
different machines. Even though installation was just as easy using GNU C-H-, installing 

the compiler itself is not so easy. The AT&T cfront compiler is much easier to use if 
available. 

The only major decision that has to be made when installing MTL is how to 
configure the software package. These options are clearly laid out in the user guide, and 
particular settings will be discussed fixrther in the next chapter. 

5. Software Settings 

SandiaXTP was written to allow the user complete control over every aspect of 
the protocol to maximize performance. This control includes: if the machine will act as 
the transmitter or a receiver; setting the group IP address; sending a status request in the 
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first packet; blocking on acknowledgment; setting fast acknowledgment; setting packet 
size; and setting buffer size. 

a. Machine Function 

There are four possibilities for this variable, all of which were used during 
the experiments detailed in Chapter IV. Setting the “-t” flag activates the machine as a 
unicast transmitter, while the “-r” flag activates the machine as a unicast receiver. Setting 
the “-T” flag activates the machine as a multicast transmitter, and the “-R” flag activates 
the machine as a multicast receiver. The receiver(s) were started prior to starting the 
transmitter, as at least one receiver must be available prior to activation of a transmitter. 

b. IP Addressing 

In unicast mode, an address must be specified, either an IP address or a 
DNS (Domain Name Server) address. In multicast mode, a Class D IP address must be 
specified. For our experiments, the default address (239.0.0.239) was used for all 
addressing. 

c. Status Request (SREQ) 

An SREQ is a bit that is set in a packet that requires the receiver of the 
packet to send back a control packet. The “-f ’ flag on the transmitter sends an SREQ in 
the “FIRST” packet sent by the transmitter. This flag causes the receiver(s) to 
acknowledge receipt of the initial packet, which tells the transmitter that the receiver(s) 
is/are active, thereby establishing the multicast group. 
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(L Block on Acknowledgment 


The “-g” flag prevents the transmitter from sending additional packets 
(i.e., “block”) until previously sent packets have been acknowledged by all receivers via 
anSREQ. 


e. Error Control 

To maximize throughput, these experiments were conducted with the 
FASTNAK” flag (“-F”) set. Use of the FASTNAK switch causes each receiver to send 
a control packet to the transmitter when an error is detected. Ideally, this control packet 
would reach the transmitter prior to any additional packets being transmitted. However, 
the high data transfer rates demonstrated by the protocol mean that packets sequenced fr)r 
transmission after the packet in error may have been sent, resulting in GO BACK N' 
retransmissions of the error packet and all later packets. Thus, GO BACK N describes a 
scheme in which once a control packet is received by the transmitter, that transmitter must 
GO BACK (in the transmission sequence) to the packet in error, and retransmit it, along 
with all successive packets. 

D. SUMMARY 

SandiaXTP’s object-oriented implementation of the XTP 4.0 specification is 
designed to be a research protocol to further advance the development of the Xpress 
Transport Protocol. Although not intended for commercial use, its tracking mechanisms, 
immediate availability and local support base made it an excellent candidate for this 
research project. The protocol’s reliability and adaptability were explored via a testbed 
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that was built to support experimentation. Software installation is simple and supports a 
wide range of current computing platforms. Being a user-space daemon means that the 
protocol is highly portable and easy to install. Additionally, XTP itself supports general 
commimications needs which satisfies the diverse requirements of the military. Finally, 
SandiaXTP supports the ability to send both reliable and unreliable datagrams by 
multicast or unicast. This is particularly important, since not all military message traffic 
requires assured delivery of data. 
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IV. EXPERIMENTS 


A. INTRODUCTION 

In Chapter II, XTP was determined to be a protocol that seems to fulfill the needs 
of the Naval Amphibious Readiness Group scenario. In Chapter III, the operating 
environment was described in which experiments would be conducted to determine the 
ability of XTP to reliably transfer data to single and multiple receivers concurrently. This 
chapter is dedicated to the description, summarization and graphical representation of 
those experiments. First, a description of the experiments is presented; this is followed by 
expectations of protocol fortuity, and finally, actual results. 

B. DESCRIPTION OF EXPERIMENTS 

Any protocol which is to be adopted for use in a military application must exhibit 
both scalability and survivability. For XTP to accomplish these goals, it must be able to 
effectively transfer messages consisting of a varying amount of data (i.e., small and large 
messages) via unicast and multicast (to increasing numbers of receivers) under varying 
error conditions. For this thesis, there will be 32 experiments, 16 of which will consist of 
the transmission of a small message, and 16 for a large message. Each of these 16 
experiments will consist of a 4 x 4 matrix made up of four transmission methods (unicast, 
and multicast wifli one, two, and three receivers), and four levels of induced errors (none, 
one in 25 packets, one in ten, and one m five). 
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1. Small Message (50 Kilobytes) 

The transmission of a 50 kilobyte message is intended to simulate the text-only 
data transfer between the Naval Beach Group and forces afloat. This message should 
include descriptions of the landing zone including surf, weather, terrain, etc., as well as 
the status of both personnel and supplies. 

2. Lai^e Message (One Megabyte) 

The one megab)de message is the simulation of sending a graphical image of the 
landing zone to the forces afloat. Frequent transmission of a single, comprehensive 
“snapshot” of the landing zone ensures that all concerned parties are in possession of a 
common tactical picture as soon as it becomes available. 

3. Transmission Method 

XTP provides both a unicast and multicast transmission service. Unicast may be 
used whenever only one recipient is to be addressed, while multicast is used for groups of 
one or more recipients. For these experiments, the multicast transmissions are sent to 
one, two, and three receivers. 

4. Induced Errors 

Under any military application, a hostile communications environment is not only 
possible, it must be considered normal. Therefore, errors will be introduced into the data 
transfer stream by choosing one receiver to drop packets. To effectively evaluate the 
performance of the transport protocol, baseline measurements (i.e., no induced errors) 
must first be taken, followed by performance measurements taken under various 
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(simulated) conditions of link effectiveness and transfer path noise. Therefore, errors will 
be introduced with means of one packet per 25 and one per 10, with the final examination 
simulating an extremely hostile communications environment and/or a very lossy 
receiver, losing on average one of every five packets. The packet loss is distributed 
uniformly about the mean. 

5. Buffer Size 

Another parameter in the experiments is the size of the buffer. This is an amount 
of reserved space in both the transmitter and receiver(s) that stores the data being 
transferred. For these experiments, the buffer size will be varied jfrom 64 bytes to 8192 
bytes, increasing by powers of two (i.e., 2^ bytes, l’ bytes, 2* bytes, etc.). The importance 
of the buffer is in the method of data transfer: the program will effect a repetitive loop 
sending an amount of data equal to the size of the buffer to the receiver(s) until all data 
has been sent and acknowledged by the receivers. Thus larger buffer sizes cause fewer 
calls to XTP to transfer the same amount of data. 

6. Number of Iterations 

With a knowledge of all the variables that influence protocol performance, it must 
now be noted that a single transmission of data will not consistently provide results 
characteristic of system capabilities. For this reason, three sets of data will be collected 
for each experiment, and the numbers will then be averaged to provide a more 
trustworthy basis for analysis. 


45 



C. EXPECTED RESULTS 


1. Introduction 

As with any set of experiments, some predictions can be to form a 

hypothesis of performance. In this case, all variables must be considered - one at a time 
— and then be compared to actual results. 

During the experiments, the “metric” test program (supplied with the SandiaXTP 
distribution) will be utilized. This will yield three values for each successful iteration: 

• Timing - the amount of time consumed in the end-to-end delivery of the 
message (in milliseconds). 

• Throughput - the measure of the rate of data delivery from end to end (in 
megabits per second). 

• Latency - the time to deliver a message from end to end (in milliseconds per 

call). ^ 

Since the most useful performance characteristic of a transport protocol is 
throughput, all performance results will be viewed in those terms. 

2. Unicast Versus Multicast 

Unicast is expected to yield hi^er throughput than multicast as multicast incurs 
overhead to manage the group of receivers. This is because XTP builds an auxiliary 
context (protocol control block) for each receiver in a multicast group (Strayer, 1997). 

3. Increasing the Number of Multicast Receivers 

Increasing the number of multicast receivers should result in lower throughput, as 
each receiver must provide the requisite acknowledgments prior to the transmitter moving 
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the send window. This means that the multicast throughput is highly dependent upon the 
performance of the slowest or most error prone receiver. If a receiver that demonstrates 
performance faster than, or equal in speed to the existing receivers is added, throughput 
should slow very slightly, as one additional acknowledgment must make it back to the 
transmitter prior to the packet transfer. However, if a slower receiver is added, 
throughput should show a more pronounced reduction. 

4. Induction of Errors 

The instance of errors in the transmission of data necessitates the retransmission 
of packets and, therefore, a baseline experiment is expected to have the highest 
throughput, while the introduction of one error per 25 packets should reduce the 
throughput by approximately 4% (one in 25). By similar argument, one error in ten 
packets should reduce the baseline throughput by 10%, and one error in five packets 

should degrade performance by 20%. Overall throughput will be determined by the 
slowest receiver. 

5. Buffer Size 

The buffer determines how much data may be transmitted in a single call to XTP. 
Since the buffer size is increased by powers of 2, the throughput should also increase 
exponentially, resulting in a linear curve. The degree of increase should be approximately 
double, tmtil reaching the maximum XTP data transfer limitation of 1448 bytes per packet 
(determined by a 1500 byte Ethernet frame minus 20 bytes for an IP header and 32 bytes 
for the XTP header). When transferring packets larger than 1448 bytes, there is 
mandatory packet segmentation and re-assembly by the transmitter and receiver(s) 
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respectively. This means that a reduction in throughput should occur for a buffer size 
slightly larger than 1448 bytes since two packets are now required. There will be an 
amortization of this effect for further increases above 1448, as well as higher multiples of 
1448, as the effects of increasing overhead are diminished. Similarly, as the amoimt of 
data to be sent is doubled, throughput should approximate a doubling minus the sum of 
Ihe costs of segmentation and re-assembly, and incurred overhead. 

D. ACTUAL RESULTS ANALYSIS (VARYING TRANSMISSION 
METHOD) 

The tables presented in this chapter depict the averages of the three iterations of 
each experiment (Appendbc A shows each of the tables of results from the three sets of 
data drawn from the experiments.). The analyses that follow relate buffer size and 
throughput for each experiment. The reason for this presentation is to demonstrate the 
scalability of XTP: how the addition of receivers (with all other parameters held 
constant) affects throughput. 

The first four sets of results examine the behavior of the implementation and 
protocol during the transmission of a 50 kilobyte (51200 byte) message with and without 
induced errors. The following four sets examine performance during transmission of a 1 
megabyte (1024000 byte) message. For each of these groups of four, the initial 
investigation is conducted in an environment of zero induced errors. The second set of 
data is the result of an induced error count of one packet per every 25. The third 
increases the induced error count to one per ten packets, and finally, the noisy 
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chaimel/lossy receiver possibility is presented as the number of lost packets reaches one 


in five. 


1. 50 Kilobyte Message Size 


a. No induced Errors 


Buffer Size 
(Bytes)_ 

Unicast 

Multicast 1:1 

Multicast 1:2 

Multicast 1:3 

64 

0.126 

0.168 

0.202 

0.198 

128 

0.284 

0.221 

0.352 

0.374 

256 

0.495 

0.477 

0.570 

0.580 

512 

1.090 

0.702 

0.804 

0.776 

1024 

1.702 


1.032 

1.021 

2048 

2.610 

0.798 

1.064 

1,101 

4096 

^735 

1.114 

1.194 

1.215 

8192 

4.537 

1.150 

1.200 

1.212 


Table 4.1 Throughput of a 50 Kbyte Message Transmitted with No Induced Errors 



Figure 4.1 Throughput of a 50 Kbyte Message Transmitted with No Induced Errors 

A message of this relatively small size is transmitted very quickly and 
therefore, small idiosyncrasies in topography state may yield unexpected results as 
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demonstrated by the smaller unicast throughput at the 64 byte buffer size (Table 4.1). 

Above this level, however, the unicast results conform to expectations, exceeding those of 
the multicast. 


The multicast transmission results demonstrate the overhead of managing 

a group of receivers. However, the addition of receivers did not significantly hamper 
throughput. 


b. Induced errors: 1 of 25 packets 


Buffer Size 
(Bytes) 

Unicast 

Multicast 1:1 

Multicast 1:2 

Multicast 1:3 

64 

0.189 

0.151 

0.159 

0.169 

128 

0.360 

0.278 

0.283 

0.319 

256 

0.673 

0.447 

0.354 

0.402 

512 

1.196 

0.689 

0.622 

0.604 

1024 

2.272 

1^912 

0.867 

0.904 

2048 

1.774 

0.983 

0.938 

0.848 

40% 

4.479 

1.085 

1.209 

1.108 

8192 

4.434 

1.176 

1.040 

0.904 


Table 4.2 Tbroughput of a 50 Kbyte Message Transmitted with Induced Errors: 1 of 25 Packets Dropped 



Figure 4.2 Throughput of a 50 Kbyte Message Transmitted with Induced Errors: 1 of 25 Packets Dropped 
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The results of the 50 Kbyte message with induced errors not only reflect a 
more realistic data transfer, they also conform more strongly to expected results. The 
unicast transmission retains the highest throughput for all buffer sizes, and exhibits an 
asymptotic increase up to and including the 1024 byte buffer level as a result of the log 
scale. This is consistent with expectations, resulting from the exponential increase in the 
buffer size. However, the reduction in throughput as the buffer is increased from 4096 
bytes to 8192 bytes deserves attention: this anomaly may be explained by the FASTNAK 
switch being set, along with XTP’s use of GO BACK N retransmission (as described in 
Chapter III). With a large buffer size, XTP’s internal buffers store numerous packets (six 
for an 8192 byte buffer) for each call to XTP. When an error occurs, several packets may 
have to be retransmitted. This will result in a “leveling off’ and possible reduction in 
throughput, as seen when the buffer is increased from 4096 bytes to 8192 bytes. This 
effect is observed in Figure 4.2, as well as on future graphs at the same buffer size 
transition. 

The multicast results show relatively constant throughput for an increasing 
number of receivers at any buffer size, which is a desired trait of a multicast protocol: 
scalability. Increasing the number of receivers does not significantly detract from system 
throughput. 
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c. 


Induced errors: 1 of 10 packets 


Buffer Size 
(Bytes) 

Unicast 

Multicast 1:1 

Multicast 1:2 

Multicast 1:3 

64 

0.120 

0.153 

0.152 

0.131 

128 

6.244 

0.275 

0.237 

0.231 

256 

0.446 

0.482 

0.387 

0.386 

512 

0.772 

0.625 


0.573 

1024 

1.402 

0.903 

0.659 

0.713 

2048 

2.156 

0.520 

0.706 


4096 

2.971 

1 

0.742 


8192 

2.551 

1 

0.749 

0.747 

No successfiil runs were completed at this 

buffer size. 



Table 4.3 Throughput of a 50 Kbyte Mess^e Transmitted with Induced Errors; 1 of 10 Packets Dropped 



Figure 4.3 Throughput of a 50 Kbyte Message Transmitted with Induced Errors: 1 of 10 Packets Dropped 


Unicast perfonns as expected, demonstrating the reduction in throughput 
as the buffer is increased from 4096 to 8192 bytes as per the explanation in the previous 
subsection. The 1024 byte buffer demonstrates (roughly) expected results with multicast 
performance remaining below that of unicast, but at a degradation level of less than 50%. 
Proceeding on to the 2048 byte level, the multicast (one receiver) transmission shows 
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unexpected behavior by exhibiting a significant reduction in throughput before failing to 
complete, while the multicast (two receivers) and multicast (three receivers) transmission 
paths demonstrate a slightly reduced - yet relatively constant - throughput. 

Failures due to timeouts can be attributed to a timing algorithm within 
XTP which monitors transmission time. In the face of errors, the algorithm does not 
know whether the channel requires a longer round trip time (RTT) due to a longer route, 
or if packets were lost, necessitating retransmission. If the wait timer (WTIMER) expires 
without a response from the receiver(s), the timer backs off exponentially and is restarted 
to allow sufficient time for message delivery. However, if several back-to-back errors 
occur, the timer backs off for a sufficiently long time, allowing an ancillary (watchdog) 
timer (CTIMEOUT) to expire. This is believed to be the cause of the failed experiments 
to multiple receivers, as the addition of receivers slows the message transfer to the speed 
of the slowest receiver. 
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d. Induced errors: 1 of 5 packets 


Buffer Size 
(Bytes) 

Unicast 

Multicast 1:1 

Multicast 1:2 

Multicast 1:3 

64 

0.168 

0.131 

0.134 

0.126 

128 

0.305 

0.230 

0.233 

0.216 

256 

0.566 

0.407 

0.349 

0.372 

512 

0.974 

0.510 

0.494 

0.533 

1024 

1.114 

^.651 

0.638 

0.718 

2048 

11.186 

0.599 

0.445 


4096 

1.945 

0.765 

2 

2 

8192 

1 * , 

0.714 

0.779 

2 

2 


Average compiled with only one set of input data 
^ No successful runs were completed at this buffer size. 


Table 4.4 Throughput of a 50 Kbyte Message Transmitted with Induced Errors; 1 of 5 Packets Dropped 



Figure 4.4 Throughput of a 50 Kbyte Message Transmitted with Induced Errors: 1 of 5 Packets Dropped 


The continuing pattern of increasing throughput with unicast leading 
multicast is shown in Figure 4.4. Performance above the 1024 byte buffer becomes 
erratic due to the segmentation and re-assembly process described in Chapter III, with a 
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cessation of success above 2048 b 5 ^es for multicast to two and three receivers due to the 
timeout algorithm. 


2. One Megabyte Message Size 


a. No induced Errors 


Buffer Size 
(Bytes) 

Unicast 

Multicast 1:1 

Multicast 1:2 

Multicast 1:3 

64 

0.108 


0.105 

0.105 

128 

0.216 

0.215 

0.210 

0.211 

256 

0.435 

0.417 

0.447 

0.445 

512 


0.884 

0.886 

0.887 

1024 

1.500 

1.489 

1.469 

1.470 

2048 

2.202 

[2.190 

2.294 

2.261 

4096 

3.629 

3.729 

3.711 

3.648 

8192 

3.522 

5.091 

5.210 

4.991 


Table 4.5 Throughput of a One Mbyte Message Transmitted with No Induced Errors 



Figure 4.5 Throughput of a One Mbyte Message Transmitted with No Induced Errors 


Transmission of a one megab 5 d:e message allows for a more realistic 
evaluation of protocol performance, as sporadic interference introduced by noisy channels 
does not have such a magnified effect on throughput. This is because the increased 
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message size reduces the impact of periodic obstructions to data transfer. Figure 4.5 
demonstrates this. 

With this larger message size, all results conform to expectations, widi one 
exception: the reduction in unicast performance when increasing the buffer size to 8192 
bytes. This anomaly catmot be readily explained. 


b. Induced errors: 1 of 25 packets 


Buffer Size 
(Bytes) 

Unicast 

Multicast 1:1 

Multicast 1:2 

Multicast 1:3 

64 

0.161 

0.118 

0.089 

0.100 

128 

0.289 

0.316 

0.177 

0.207 

256 

0.572 

0.610 

0.383 

0.419 

512 

1.116 

1.167 

0.673 

0.668 

1024 

2.025 

1.648 

1.071 

1.080 

2048 

3.161 

1.515* 

1.871 

2.041 

4096 

3.556 

2.140 

3 

I - 

8192 

3.607 

2.622^ 

3 

3 


' Average compiled with only one set of iiq)ut data. 

^ Average compiled with only two sets of input data 
^No successful runs were completed at this buffer size. 


Table 4.6 Throughput of a One Mbyte Message Transmitted with Induced Errors: 1 of 25 Packets Dropped 
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Figure 4.6 Throughput of a One Mbyte Message Transmitted with Induced Errors: 1 of 25 Packets 
Dropped 


Figure 4.6 shows the throughput of a one megabyte message transmitted 
with the induction of one in 25 errors. Unicast performance shows the expected 
exponential increase up to a buffer size of 1024 bytes, and a reduction in performance 
increases for subsequent increases in buffer size. T his is due to the XTP 1448 byte packet 
size and the requirement for packet segmentation and re-assembly as discussed earlier. 

Multicast throughput is somewhat less, with one item of note; at the 2048 
b54e buffer level with transmission to one receiver, an unevenness in the performance 
graph is due to only one successful run at these parameters. With only one set of data to 
rely on, the effects of averaging three runs is eliminated, and less trustworthy data is 
provided as input to the graph. In this case, that single successful run yielded slower than 
expected throughput. 
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Induced errors: 1 of 10 packets 


c. 


Buffer Size 
(Bytes) 

Unicast 

Multicast 1:1 

Multicast 1:2 

Multicast 1:3 

64 


0.033 


0.087 

128 

0.222 

0.075 

0.152 

0.182 

256 

0.429 

0.327 

0.311 

0.365 

512 

0.809 


0.730 

0.710 

1024 

1.422 

1.015 

1.226 

rijii 

2048 

1.892 

1.504 

1.408 

3 

4006 

2314 

1.531 

1.770 

3 

8192 

1 A_ M , 

1.447 

2.124^ 

1.748^ 

3 


' Average compiled with only one set of inp ut Ha fg 
^ Average compiled with only two sets of input data 
^No successful runs were completed at this buffer size. 


Table 4.7 Throughput of a One Mbyte Message Transmitted with Induced Errors: 1 of 10 Packets Dropped 



Figure 4.7 Throughput of a One Mbyte Message Transmitted with Induced Errors: 1 of 10 Packets 
Dropped 


Figure 4.7 shows the increasing degradation of throughput as the number 
of induced errors is increased to one in ten packets. All results are to be expected, 
remembering that the Ethernet limitation of packet size hampers performance increases 
beyond the 1024 byte buffer, and that the watchdog timer expiration may result in an 
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unsuccessful experiment run. This is the case in multicasting to three receivers with a 
buffer size larger tiian 1024 bytes. 


d. Induced errors: 1 of 5 packets 


Buffer Size 
(Bytes) 

Unicast 

Multicast 1:1 

Multicast 1:2 

Multicast 1:3 

64 


0.107 

0.052 


128 

0.222 

0.194 

0.153 




0.372 

0.318 

|]S£9HHH 


0.775 

0.644 

0.709 


1024 

1.332 


0.945 


2048 

^989 

1.223 

0.970 


4096 

0.267 


1- 

2 

8192 

0.541 

4 _ _ J. • 

2 ^ 

2 

2 


’ Average compiled with only two sets of input Hatg 
No successful runs were completed at this buffer size. 


Table 4.8 Throughput of a One Mbyte Message Transmitted with Induced Errors: 1 of 5 Packets Dropped 



Figure 4.8 Throughput of a One Mbyte Message Transmitted with Induced Errors; 1 of 5 Packets Dropped 


The increase in induced errors to one in five yields the graph depicted in 
Figure 4.8. Once again, the results up to and including the buffer size of 1024 bytes are 
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in line with expectations. Coincidentally, it is beyond this 1 kilobyte level that successful 
multicast transmission to three receivers is lost. Multicasting to two receivers is lost 
beyond the next larger buffer size (2048 bytes), with multicast to one receiver failing for 
the 8192 byte buffer size. This phenomenon is explained by the combination of the 
required retransmissions of large size packets consuming sufficient amoimts of time to 
activate the watchdog timer shutdown mechanism. 

While imicast transmission operates successfully throughout the range of 
buffer sizes, considerable degradation occurs beyond the 1024 byte buffer, as with 
multicast (as a whole). 

3. Transmission Method Analysis Summary 

Generally, the figures above depict expected protocol performance up to and 
including a buffer size of one kilobyte. Beyond this, the Ethernet packet size limitation of 
1448 bytes obligates packet segmentation by the transmitter, and re-assembly by the 
receiver(s). This, combined with the introduction of induced errors and the resulting 
watchdog timer influence, results in negligible — and sometimes negative — performance 
increases at larger buffer sizes. XTP was shown to be scalable up to three receivers as 
there is no appreciable change in throughput as the number of receivers is increased. 


E. ACTUAL RESULTS ANALYSIS (VARYING INDUCED 
ERRORS) 

The previous subsection concentrated on an analysis of throughput variations as 
the transmission method shifted from unicast to multicast, and the subsequent addition of 
receivers to the multicast transfer of data. This was done to examine the scalability of 
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XTP. Now the effect of the inclusion of an increasing amount of errors on a given 
transmission method is examined. This analysis is intended to demonstrate the 
survivability of the protocol. 

1. 50 Kilobyte Message Size 


fl. Unicast 


Buffer Size 
(Bytes) 

No Induced 
Errors 

1 of 25 Packets 
Dropped 

1 of 10 Packets 
Dropped 

1 of 5 Packets 
Dropped 

64 


EakSHHHI 


0.168 

128 

0.284 

ESSIHHHi 

0.244 

ESIiSHHiH 

256 

0.495 

0.673 



512 


1.196 


0.974 


1.702 

2.272 


1.114 

EllESHHHi 

2.610 

'2.774 

2.156 

1.186 


3.735 

4.479 

2.971 

1.945 

1 8192 

4.537 

4.434 

2.551 

0.714 


Table 4.9 Throughput of a 50 Kbyte Unicast Message with Varying Induced Errors 



Figure 4.9 Throughput of a 50 Kbyte Unicast Message with Varying Induced Errors 
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Figure 4.9 shows the effects of inducing errors into a unicast transmission 
of a small (50 kilobyte) message. While it is expected that increasing the amoimt of 
errors (from one in 25, to one in ten, to one in five) will result in a slower throughput, as 
is the case; it is surprising that throughput rose in the transition from “no induced errors” 
to “one in 25 packets”. This can be explained by the transmission of control packets in a 
FASTNAK scheme ironically raising throughput. 

The prompt sending of a control packet by a receiver signaling an error 
(and resulting in packet retransmission) interrupts the flow of data packets by the 
transmitter and initiates the GO BACK N retransmission scheme. With buffer sizes less 
than 1448 bytes, the retransmitted data may be piggy-backed onto previously scheduled 
packets (filling in the available space in each packet). By filling the available space 
within each packet to a greater degree, throughput does not suffer, as shown in Figure 
4.9. This phenomenon does not show increased throughput beyond the initial error level 
of one packet per 25, as the ramp up to one in ten yields a greater effect of timing delay 
and the inherent reduction in throughput due to the GO BACK N reh^smission scheme 
in the face of many errors. 


62 



b. 


Multicast to One Receiver 


Buffer Size 
(Bytes) 

No Induced 
Errors 




64 

0.168 

0.151 

0.153 

0.131 

128 

0.221 

0.278 

0.275 

0.230 

256 

0.477 

0.447 

0.482 

0.407 

512 

0.702 

0.689 

0.625 

0.510 

1024 

0.916 

0.912 

0.903 

0.651 

2048 

0.798 

0.983 

0.520 

0.599 

4096 

rL114 

1.085 

1 

0.765 

8192 

1 

1.150 

1.176 

1 

0.779 


' No successful runs were completed at this buffer size. 


Table 4.10 Throughput of a 50 Kbyte Multicast (One Receiver) Message with Varying Induced Errors 



Figure 4.10 Throughput of a 50 Kbyte Multicast (One Receiver) Message with Varying Induced Errors 


Figure 4.10 shows the effects of varying the number of induced errors on a 
multicast transmission to one receiver. While the disparity between “no errors” and “one 
in 25 is greatly reduced, there is an unusual termination of successful experimentation 
above a buffer size of 2048 bytes with one error in ten packets, as noted earlier. 


63 










































Multicast to Two Receivers 


Buflfer Size 

No Induced 

1 of 25 Packets 

1 of 10 Packets 

1 of 5 Packets 

(Bytes) 

Errors 


Dropped 

Dropped 

64 

0.202 

0.159 

0.152 

0.134 

128 

0.352 

0.283 

0.237 

0.233 

256 

0.570 

0.354 

0.387 

0.349 

512 

0.804 

0.622 

0.598 

0.494 

1024 

1.032 


10.659 

0.638 

2048 

1.064 

0.938 

0.706 

0.445 

4096 

1.194 

1.209 

0.742 

1 

8192 

1.200 

1.040 

0.749 

1 

^ No successful runs were completed at this 

buffer size. 


Table 4.11 Throughput of a 50 Kbyte Multicast (Two Receivers) Message with Varying Induced Errors 



Figure 4.11 Throughput of a 50 Kbyte Multicast (Two Receivers) Message with Varying Induced Errors 


Figure 4.11 demonstrates expected results: throughput is reduced as the 
number of errors is increased, and the single instance of unsuccessful transmission occurs 
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at the highest error rate, and at the higher buffer levels. This is due to expiration of the 
watchdog timer. 


d. Multicast to Three Receivers 


Buffer Size 
(Bytes) 

No Induced 
Errors 



1 of 5 Packets 
Dropped 

64 

0.198 

0.169 

0.131 

0.126 

128 

0.374 

0.319 

0.231 

0.216 

256 

0.580 

0.402 

0.386 

0.372 

512 

0.776 

0.604 

0.573 

0.533 

1024 

1.021 

0.904 

0.713 

0.718 

2048 

1.101 

0.848 

0.704 

0.679* 

4096 

1.215 

1.108 

0.806 

2 

8192 

1.212 

0.904 

0.747 

2 


’ Average compiled with only one set of input data. 

^ No successful runs were completed at this buffer size. 


Table 4.12 Throughput of a 50 Kbyte Multicast (Three Receivers) Message with Varying Induced Errors 



Figure 4.12 Throughput of a 50 Kbyte Multicast (Three Receivers) Message with Varying Induced Errors 
The multicast transmission to three receivers depicted in Figure 4.12 
conforms to expectations. Worthy of note is the similarity to Figure 4.11 both visually 
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and numerically: performance remains stable with the addition of another receiver with 
no appreciable change in throughput. This indicates scalability. 


2. One Megabyte Message Size 


a. Unicast 


Buffer Size 

No Induced 




(Bytes) 

Errors 




64 

0.108 

0.161 

0.108 

0.107 

128 

0.216 

0.289 

0.222 

0.222 

256 

0.435 

0.572 

0.429 

0.420 

512 

0.850 

1.116 

0.809 

0.775 

1024 

1.500 

2.025 

1.422 

1.332 

2048 

2.202 

3.161 

1.892 

0.989 

4096 

3.629 

3.556 

2.374 

0.267 

8192 

3.522 

i607 

1.447 

0.541 


Table 4.13 Throughput of a One Mbyte Unicast Message with Varying Induced Errors 



Figure 4.13 Throughput of a One Mbyte Unicast Message with Varying Induced Errors 
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Figure 4.13 shows the unicast transfer of a one megabyte message. This 
larger message size acts to stabilize inconsistencies prevalent in noisy channels and the 
effects of errors on small messages. Highly predictable results are seen at buffer sizes up 
to and including 1024 bytes, with continuing predictable data in all curves, except for the 
worst case of one lost packet in five. The severe loss in throughput is attributable to the 
reduction in throughput resulting firom many retransmissions. 


b. Multicast to One Receiver 


Buffer Size 
(Bytes) 

No Induced 
Errors 

1 of 25 Packets 
Dropped 

1 of 10 Packets 
Dropped 

1 of 5 Packets 
Dropped 

64 

0.104 

0.118 

0.033 

0.107 

128 

0.215 

0.316 

0.075 

0.194 

256 

0.417 

0.610 

0.327 

0.372 

512 

0.884 

1.167 

0.657 

0.644 

1024 

1.489 

1.648 

1.015 

1.060 

2048 

2.190 

1.515’ 

1.504 

1.223 

4096 

3.729 

1.140 

1.531 


8192 

1 * , 

5.091 

2.622^ 

2.124’ 



' Average compiled with only one set of input data 
^ Average compiled with only two sets of input data 
^o successful runs were completed at this buffer giyp 


Table 4.14 Throughput of a One Mbyte Multicast (One Receiver) Message with Varying Induced Errors 
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Figure 4.14 Throughput of a One Mbyte Multicast (One Receiver) Message with Varying Induced Errors 

The shift to a multicast transmission (independent of the number of 
receivers) has smoothed protocol performance and produced expected results The 
introduction of errors results in a decrease in throughput, and there is an eventual 
attainment of non-successfiil experimentation under worst case conditions. 


c. Multicast to Two Receivers 


Buffer Size 
(Bytes) 

No Induced 
Errors 


1 of 10 Packets 
Dropped 

1 of 5 Packets 
Dropped 

64 

0.105 

0.089 

0.061 

0.052 

128 

0.210 

0.177 

0.152 

0.153 

256 

0.447 


0.311 

0.318 

512 

0.886 



0.709 

1024 

1.469 

1.071 

1.226 

0.945 

2048 

2.294 

1.871 

1.408 

0.970 

4096 

3.711 

2 


2 

8192 

1 A , 

5.210 

2 


2 


' Average compiled with only two sets of input data. 

^ No successful runs were completed at this buffer size. 


Table 4.15 Throughput of a One Mbyte Multicast (Two Receivers) Message with Varying Induced Errors 
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Figure 4.15 Throughput of a One Mbyte Multicast (Two Receivers) Message with Varying Induced Errors 
Figure 4.15 shows a multicast transmission to two receivers. Other than 
the unexpected halting of experiment success beyond 2048 bytes for both one of 25 errors 
and one in five errors, results are predictable. 


d. Multicast to Three Receivers 


Buffer Size 
(Bytes) 

No Induced 
Errors 

1 of 25 Packets 
Dropped 

1 of 10 Packets 
Dropped 

1 of 5 Packets 
Dropped 

64 

0.105 

0.100 

0.087 

0.085 

128 

0.211 

0.207 

0.182 

ESISHHH 

256 

0.445 

0.419 

0.365 


512 

0.887 

0.668 

0.710 


1024 

1.470 

1.080 

1.211 

1.033 

2048 

2.261 

2.041 

\ 

1 

4096 

3.648 

1 

1 

1 

8192 

1 ^ ^ ^ - 

4.991 

1 

1 

\ 


‘ No successful runs were completed at this buffer size. 


Table 4.16 Throughput of a One Mbyte Multicast (Three Receivers) Message with Varying Induced Errors 
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Figure 4.16 Throughput of a One Mbyte Multicast (Three Receivers) Message with Varying Induced Errors 


The survivability of XTP is shown best in Figure 4.16. This graph depicts 
a graduation to the maximum number of induced errors while multicasting to the 
maximum number of receivers (three). Throughput remains relatively constant in the face 
of increasing taxation on protocol retransmission capabilities. 

3. Variation of Induced Errors Analysis Summary 

In general, the figures in this subsection conform to expectations by depicting a 
reduction in throughput as the number of induced errors is increased. The survivability of 
XTP is shown by repetitively high — and relatively stable -- throughput levels 
(approximately one megabit per second for the large message) in the face of increasing 
errors. However, timer settings impeded the satisfactory completion of transmissions 
which combined high error rates with multicasting. Additionally, performance above a 
buffer size of 4096 bytes became extremely untrustworthy and included numerous 
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experiment failures, due to segmentation and re-assembly combined with an increasing 
numbers of errors. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

1. Viability of Reliable Multicast 

The military needs reliable multicast because in many circumstances (e.g., a 
tactical theater), a single transmitter needs to send information to many destinations under 
both hostile conditions and conditions of limited bandwidth. It is also important that all 
participating units have the same information as soon as it becomes available. Unlike 
unicast, which is a point-to-point data transfer method, multicast provides data transfer 
capabilities to numerous receivers simultaneously. The results of the experiments 
conducted show that data can be transmitted to multiple receivers under d ynami c buffer 
and error conditions while maintaining a relatively consistent throughput. 

2. Reliable Multicast Concerns 

While running experiments, there was one significant anomaly noted; data 
transfer at buffer sizes above one kilobyte were frequently unpredictable and periodically 
unsuccessful. This was most likely due to the Ethernet connection which restricted 
packet size to 1448 bytes. Buffer sizes above this mandate a segmentation and re¬ 
assembly process which hampers throughput and could foster timeout errors. On the 
other hand, these errors may have resulted from the testbed that was subject to 
workstation loading. 
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a. 


Wait Timers 


When a packet is sent with the SREQ bit set, a wait timer (WTIMER) is 
started. If the transmitter does not receive an acknowledgment from the receiver(s) 
within the specified time after sending a packet, the timer will expire, starting a 
synchronizing handshake. In the synchronizing handshake the transmitter sends a control 
packet with SREQ set, and restarts the WTIMER. No data can be sent during the 
synchronizing handshake. The synchronizing handshake is guarded by an anc illar y tim er 
(CTIMEOUT), set in SandiaXTP to be 60 seconds. Completion failures were caused by 
the expiration of the CTIMEOUT during conducted experiments. 

XTP uses lost packets to reset a Round Trip Timer (RTT). Because the 
actual routing pathway varies due to d5mamic changes in the network, packet delivery 
times will vary as well. Since this only occurs under conditions where the route changes, 
the implementation of the backoff timer with the existing testbed topology was more 
harmful than helpful. This is simply because packets never left the gateway and a reroute 
was not possible. 

These failures are disturbing and xmacceptable in a tactical environment, 
so further testing must be conducted. However, it should be noted that this phenomenon 
could be solved by either setting the CTIMEOUT to larger values (20 minutes may be 
more appropriate), or by redesigning the synchronizing handshake to stop backing off 
exponentially once the values become large. Moreover, scalability also becomes an issue 
when considering wait timers, because more wait timers equates to greater overhead. 
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b. Go Back N and Buffer Sizes 

When a retransmission is requested, the transmitter resends every thin g 
from the point of lost data on. The larger the buffer size, the more data — on average — to 
be retransmitted. In the presence of errors, there is a greater likelihood of the 
retransmitted data also getting lost when a lot of data is being retransmitted. This would 
cause further delay, and possibly set up conditions described above where the WTIMER 
grows large. The larger the WTIMER value, the more likely the CTIMEOUT will expire, 
aborting the connection. The use of a selective retransmission scheme could help reduce 
the effect of reduced throughput in lossy situations. 

3. Testbed Concerns 

The experiments described in Chapter IV were conducted on workstations in an 
operational network laboratory, with no restriction on use by others. The lack of a 
dedicated system may have increased experiment result variation due to the existing 
collision domain, although it is believed that this was not a major factor. 

4. Summary 

This thesis examined the feasibility of adopting XTP as a reliable multicast 
protocol to fulfill the needs of military combat data transfer. The protocol supports both 
unicast and multicast transmissions, with the addition of receivers producing a negligible 
impact on multicast throughput. Small and large files were successfully transferred to 
multiple receivers with throughputs in excess of one megabit per second. Occasional 
throughput levels exceeding five megabits per second were achieved, despite the Ethernet 
maximum data transfer rate of ten megabits per second. 
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XTP demonstrated survivability by maintaining successful data fransfers to 
multiple receivers despite an increasing number of induced packet transfer errors, up to a 
tested level of 20% packet loss. Additionally, XTP is well suited to the requirement to 
adapt to a wide variety of hardware configurations. Because this variability of platforms 
is the norm in the military, the capability is essential in the reliable multicast protocol. 

B. RECOMMENDATIONS 

1. Expansion of this Study 

The e)q>eriments conducted in support of this thesis were designed to verify the 
capability of XTP to successfully transfer data to multiple receivers under conditions of 
increasing errors. There are modifications to both the topology and the hardware that 
may be undertaken to further examine the potential for XTP to fulfill the requirements of 
a military reliable multicast protocol. 

a. Remote Receivers 

The experiments described in Chapter IV were restricted to a transmitter 
and receiver located within the same network segment. The inclusion of one or more 
receivers physically located at a site that requires routing via the Internet would allow 
examination of the protocol under imbalanced roundtrip times. The Internet also provides 
packet loss due to congestion on a dynamic scale that can not be predicted by operators, 
and therefore, performance measurements using this data pipe should be conducted. 
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b. Number of Receivers 


Scalability is one of the most important features of a multicast protocol. 
While a three receiver scenario is sufficient for the tests presented in Chapter II, many 
military operations will involve more receivers. Increasing the number of receivers under 
given experiment conditions would yield valuable throughput observations and possibly 
reveal a maximum number of recipients. 

c. Types of Receivers 

Figure 3.2 showed the various platforms that are capable of r unnin g the 
SandiaXTP program. While this thesis utilized Sun SPARC4 workstations for the 
transmitter and all receivers, the use of a mix of compatible platforms (e.g., PC’s, SGI’s, 
etc.) would yield results indicative of operating with different military units. 

2. Translation of this Study 

a. Varying the Existing Experiment 

XTP contains numerous tunable parameters, such as timers. Throughout 
the course of this study, it has been discovered that under stressful conditions, the settings 
of the timers may show a significant impact on data transmission results, especially for 
large files. For this reason, bulk data transfer should be done with more status requests 
during the normal course of the transmission, to help smooth the movement of the timer 
window. Making use of selective retransmission may also help here as well. 
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b. Use of Different Protocols 

This thesis has shown that XTP is capable of fulfilling the military’s needs 
for a reliable multicast protocol. Further research could compare the results in Chapter 
IV with the conduct of the same experiments using a different protocol. T his is important 
in that any adopted protocol will most likely have attributes that come from several 
different protocols. However, it is important that XTP continues to be tracked as the 
specification matures so that further assessments can be made. 

3. Fleet Implementation and Testing 

Experiments conducted in a laboratory environment can provide- very useful 
information to determine the applicability of prospective system acquisitions and 
significantly contribute to protocol enhancements. However, it is testing in the intended 
operating environment that will produce the most beneficial knowledge. The testbed for 
this study was created on a terrestrial topology; however, the intended operating 
environment based on die scenario will be a radio based topology. Therefore, as the 
protocol matures and deployment is possible, the protocol should be tested with a radio 
based topology in order to compare results. 
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APPENDIX - TABLES OF EXPERIMENT RESULTS 


Note: Empty spaces indicate an unsuccessful run. 

Unicast Transmission from One Transmitter to One Local Receiver 
50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 

(milliseconds 

ner calll 

64 

3044 

0.135 

800 


128 

1214 

0.337 

400 

3.035 

256 

899 

0.456 

200 

4.495 

512 

427 

[ 0.959 

100 

4.270 

1024 

[750 ^ 

0.546 

\50 


2048 

168 

2.438 

25 




3.758 

13 

8.385 

1 8192 

104 

3.938 

7 

14.857 


Buffer Size 
(Bytes) 

np« • 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3387 

0.121 

800 

4.234 

128 

1748 

0.234 


4.370 

256 

842 

0.486 

200 

4.210 

512 

315 


100 

3.150 

1024 

!224 

1.829 


14.480 

2048 

138 

2.968 

25 

5.520 


139 

2.947 

13 

10.692 

1 8192 

Dam ^2 

99 

4.137 

7 



Buffer Size 
(Bytes) 

nn* • 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3319 

0.123 

ESIiHIIIH 

4.149 

128 

1463 



3.658 

256 

756 

0.542 

EHHHHi 

3.780 

512 

405 

1.011 


ESSSIHH 

1024 

150 

^731 

50 


2048 

169 

2.424 

25 

6.760 

4096 

91 

4.501 

13 


8192 

74 

5.535 

7 

10.571 
























Unicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 25 Packets) 

50K Message Size (51200 bytes) 




Run 1 

Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

64 

2261 

0.181 

128 

1117 

0.367 

256 

652 

0.628 

512 

364 

1.125 

1024 

166 

2.467 

2048 

136 

3.012 

4096 

85 

4.819 

8192 

104 

3.938 

Run 2 

Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

64 

2137 

0.192 

128 

1172 

0.349 

256 

603 

0.679 

512 

335 

1.223 

1024 

229 

1.789 

2048 

160 

2.560 

4096 

102 

4.016 

8192 

79 

5.185 


Number of 
calls 



Number of 
calls 



Run 3 



Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

64 

2107 

128 

1126 

256 

575 

512 

330 

1024 

160 

2048 

149 

4096 

89 

8192 

98 


Throughput 
(Megabits per 
second) 

Number of 
calls 

0.194 

800 

0.364 

400 

0.712 

200 

1.241 

100 

2.560 

50 

2.749 

25 

4.602 

13 

4.180 

7 
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Unicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 10 Packets) 

50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3145 

0.130 

800 

3.931 

128 

1612 

0.254 

400 

4.030 

256 

1034 

0.396 

200 

5.170 

512 

716 

0.572 

100 

7.160 

1024 

421 

0.973 

50 

8.420 

2048 

389 

1.053 

25 

15.560 

4096 

130 

3.151 

13 

10.000 

8192 

157 

2.609 

7 

22.429 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3702 

0.111 

800 

4.628 

128 

1671 

0.245 

400 

4.178 

256 

894 

0.458 

200 

4.470 

512 

481 

0.852 

100 

4.810 

1024 

295 

1.388 

50 

5.900 

2048 

130 

3.151 

25 

5.200 

4096 

110 

3.724 

13 

8.462 

8192 

166 

2.467 

7 

23.714 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3401 

0.120 

800 

4.251 

128 

1766 

0.232 

400 

4.415 

256 

848 

0.483 

200 

4.240 

512 

459 

0.892 

100 

4.590 

1024 

222 

1.845 

50 

4.440 

2048 

181 

2.263 

25 

7.240 

4096 

201 

2.038 

13 

15.462 

8192 

159 

2.576 

'7 

22.714 


81 















































































































Unicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 5 Packets) 

50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2332 

0.176 

800 

2.915 

128 

1240 

0.330 

400 

3.100 

256 

661 

0.620 

200 

3305 

512 

359 

1.141 

100 

3.590 

1024 

r302 

1.356 

50 

6.040 

2048 

240 

1.707 

25 

9.600 

40% 

200 

2.048 

13 

15.385 

8192 

464 

0.883 

7 

66.286 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2742 

0.149 

800 

3.428 

128 

1657 

0.247 

400 

4.143 

256 

665 

0.616 

200 

i325 

512 

359 

1.141 

100 

3.590 

1024 

370 

1.107 

50 

7.400 

2048 

356 

1.151 

25 

14.240 

4096 

197 

2.079 

13 

15.154 

8192 

502 

0.816 

7 

71.714 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2306 

0.178 

800 

2.882 

128 

1208 

0.339 

400 

3.020 

256 

884 

0.463 

200 

4.420 

512 

639 

0.641 

100 

6.390 

1024 

466 

0.879 

50 

9.320 

2048 

^5 

0.700 

25 

23.400 

4096 

^40 

^.707 

T3 

18.462 

8192 

927 

0.442 

7 

132.429 


82 
















































































































Multicast Transmission from One Transmitter to One Local Receiver 
50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2380 

0.172 

800 

2.975 

128 

2174 

0.188 

400 

5.435 

256 

857 

0.478 

200 

4.285 

512 

563 

0.728 

[lOO 

5.630 

1024 

412 

0.994 

50 

8.240 

2048 

659 

0.622 

25 

26.360 

4096 

^25 

^ 1.260 

13 

25.000 

8192 

436 

0.939 

7 

62.286 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2123 

0.193 

800 

2.654 

128 

1632 

0.251 

400 

4.080 

256 

845 

0.485 

200 

4.225 

512 

608 

0.674 

100 

6.080 

1024 

477 

0.859 

50 

9.540 

2048 

661 

0.620 

25 

26.440 

4096 

354 

1.157 

13 

27.231 

8192 

326 

1.256 

7 

46.571 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 


Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2962 

0.138 

800 

3.703 

128 

1821 

0.225 

400 

4.553 

256 

875 

0.468 

200 

4.375 

512 

581 

0.705 

100 

5.810 

1024 

458 

0.894 

50 

9.160 

2048 

356 

1.151 

25 

14.240 

4096 

443 

0.925 

13 

34.077 

8192 

326 

1.256 

7 

46.571 


83 



























































































































Multicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 25 Packets) 

50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2661 

0.154 

800 

3.326 

128 

1502 

0.273 

400 

3.755 

256 

956 

0.428 

200 

4.780 

512 

571 

0.717 

100 

5.710 

1024 

478 

0.857 

50 

9.560 

2048 

461 

0.889 

25 

18.440 

4096 

353 

1.160 

13 

27.154 

8192 

376 

1.089 

7 

53.714 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2786 

0.147 

800 

3.482 

128 

1444 

0.284 

400 

3.610 

256 

849 

0.482 

200 

4.245 

512 

602 

0.680 

100 

6.020 

1024 

439 

0.933 

50 

8.780 

2048 

382 

1.072 

25 

15.280 

4096 

416 

0.985 

13 

32.000 

8192 

331 

1.237 

7 

47.286 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Ml 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2674 

0.153 

800 

3.342 

128 

1485 

0.276 

400 

3.712 

256 

948 

0.432 

200 

4.740 

512 

612 

0.669 

100 

6.120 


433 

0.946 

50 

8.660 

EHElHHHi 

415 

0.987 

25 

16.600 

4096 

369 

1.110 

13 

28.385 

8192 

341 

1.201 

7 

48.714 


84 





















































































































Multicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 10 Packets) 

50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2921 

0.140 

800 

3.651 

128 

1404 

0.292 

400 

3.510 

256 

868 

0.472 

200 

4.340 

512 

644 

0.636 

100 

6.440 

1024 

448 

0.914 

50 

8.960 

2048 

r^9 

[0.594 

25 

27.560 

4096 





8192 






Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2563 

0.160 

800 

3.204 

128 

1673 

0.245 

400 

4.183 

256 

841 

0.487 

200 

4.205 

512 

613 

0.668 

100 

6.130 

1024 

455 

0.900 

50 

9.100 

2048 

483 

0.848 

25 

19.320 

4096 





8192 






Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2582 

0.159 

800 

3.228 

128 

1417 

0.289 

400 

3.542 

256 

841 

0.487 

200 

4.205 

512 

717 

0.571 

[loo 

7.170 

1024 

458 

0.894 

50 

9.160 

2048 

3504 

0.117 

25 

140.160 

4096 





8192 






85 

























































































Multicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 5 Packets) 

50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2888 

0.142 

800 

3.610 

128 

1708 

0.240 

400 

4.270 

256 

1028 

0.398 

200 

5.140 

512 

870 

0.471 

100 

8.700 

1024 

557 

0.735 

50 

11.140 

2048 

^4 

0.782 

25 

20.960 

4096 

432 

0.948 

T3 

33.231 

8192 

498 

0.822 

7 

71.143 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3085 

0.133 

800 

3.856 

128 

1747 

0.234 

400 

4.367 

256 

995 

0.412 

200 

4.975 

512 

880 

0.465 

100 

8.800 

1024 

915 

0.448 

50 

18300 

2048 

725 

0.565 

25 

29.000 

4096 

779 

0.526 

13 

59.923 

8192 

653 

0.627 

7 

93.286 


Run 3 


Buffer Size 
(Bytes) 

FTn* • 

Timing 

(mUUseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3456 

0.119 

800 

4.320 

128 

1898 

0.216 

400 

4.745 

256 

993 

0.412 

200 

4.965 

512 

690 

0.594 

100 

6.900 

1024 

532 

0.770 

50 

ITo.640 

2048 

912 

0.449 

25 

36.480 

4096 

498 

0.822 

13 

38.308 

8192 

462 

0.887 

7 

66.000 


86 








































































































Multicast Transmission from One Transmitter to Two Local Receivers 
50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

EH 

Number of . 
calls 

Latency 
(milliseconds 
per call) 

64 

1882 

0.218 

800 

2.353 

128 

1092 

0.375 

400 

2.730 

256 

660 

0.621 

200 

3.300 

512 

481 

0.852 

100 

4.810 

1024 

429 

0.955 

50 

8.580 

2048 

360 

1.138 

25 

14.400 

4096 

376 

1.089 

13 

28.923 

8192 

329 

1.245 

7 

47.000 


Run 2 



Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

64 

2507 

128 

1427 

256 

862 

512 

583 

1024 

381 

2048 

398 

4096 

329 

8192 

325 



E 


0.163 


0.287 


.475 


0.703 


1.075 


1.029 


1.245 


1.260 


Number of 
calls 




3.134 


3.567 


4.310 


5.830 


7.620 


15.920 


25.308 


46.429 



Buffer Size 
(Bytes) 

64 

128 

256 

512 

1024 

2048 

4096 

8192 


Timing 


(milliseconds) 



374 



87 












































































































Multicast Transmission from One Tran: 
with Induced Errors (1 of 25 Packets) 
50K Message Size (51200 bytes) 


Run 1 


Buffer Size 

Timing 

(Bytes) 

(milliseconds) 

64 

2514 

00 

1313 

256 

1133 

512 

587 

1024 

452 

2048 

510 

4096 

340 

8192 

368 

Run 2 

Buffer Size 

Timing 

(Bytes) 

(milliseconds) 

64 

2086 

128 

1771 

256 

1127 

512 

706 

1024 

486 

2048 

405 

4096 

330 

8192 

348 

Run 3 

Buffer Size 

Timing 

(Bytes) 

(milliseconds) 

64 

3448 

128 

1341 

256 

1219 

512 

696 

1024 

480 

2048 

409 



0.163 


0.312 


0.362 


0.698 


0.906 


0.803 


1.205 


1.113 



.196 


0.231 


0.363 


0.580 


0.843 


1.011 


1.241 


1.177 



c 


>96 

347 

92 

494 


0.119 


305 


0.336 


0.589 


.853 


1.001 



to Two Local Receivers 


ughput 
abits per 
d) 

Number of 
calls 

Latency 
(milliseconds 
per call) 


800 

3.143 


400 

3.283 


200 

5.665 


100 

5.870 


50 

9.040 


r25 

20.400 


13 

26.154 


7 

52.571 


ighput 
tbits per 

i) 

Number of 
calls 

Latency 
(mUliseconds 
per call) 


800 

2.607 


400 

4.428 


200 

5.635 


100 

7.060 


50 

9.720 


25 

16.200 



25.385 


7 

49.714 


ghput 
bits per 
») 


Latency 
(milliseconds 
per call) 


800 

4.310 


400 

3.353 


200 

6.095 


100 

6.960 


50 



25 



13 

26.692 


7 

70.571 


88 












































































































Multicast Transmission from One Transmitter to Two Local Receivers 
with Induced Errors (1 of 10 Packets) 

50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3086 

0.133 

800 

3.857 

128 

1783 

0.230 

400 

4.457 

256 

1091 

0.375 

200 

5.455 

512 

658 

0.622 

100 

6.580 

1024 

560 

0.731 

50 

11.200 

2048 

597 

0.686 

25 

23.880 

4096 

548 

0.747 

13 

42.154 

8192 

406 

1.009 

7 

58.000 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2541 

0.161 

800 

3.176 

128 

1729 

0.237 

400 

4.322 

256 

1012 

0.405 

200 

5.060 

512 

730 

0.561 

100 

7.300 

1024 

636 

0.644 

50 

12.720 

2048 

574 

0.714 

25 

22.960 

4096 

935 

0.438 

^3 

71.923 

8192 

642 

0.638 

7 

91.714 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2528 

0.162 

800 

3.160 

128 

1681 

0.244 

400 

4.202 

256 

1071 

0.382 

200 

5.355 

512 

672 

0.610 

100 

6.720 

1024 

681 

0.601 


13.620 

2048 

570 

0.719 

25 

22.800 

4096 

393 


13 

30.231 

8192 

681 

OSHlHiHi 

7 

97.286 


89 

















































































































Multicast Transmission from One Transmitter to Two Local Receivers 
with Induced Errors (1 of 5 Packets) 

50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2954 

6.139 

800 

3.692 

128 

1790 

0.229 

400 

4.475 

256 

1195 

0.343 

200 

5.975 

512 

805 

0.509 

100 

8.050 

1024 

625 

0.655 

50 

12.500 

2048 

1264 

0.324 

25 

50.560 

4096 





8192 






Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 


Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3138 

0.131 

800 

3.922 

128 

1750 

0.234 

400 

4.375 

256 

1210 

0.339 

200 

6.050 

512 

717 

0.571 

100 

7.170 

1024 

722 

0.567 

50 

14.440 

2048 

764 

0.536 

25 

30.560 

4096 





8192 






Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3075 

0.133 

800 

3.844 

128 

1731 

0.237 

400 

4.327 

256 

1125 

0.364 

200 

5.625 

512 

1021 

0.401 

100 

10.210 

1024 

593 

0.691 

50 

11.860 

2048 

860 

0.476 

25 

34.400 

4096 





8192 







90 





































































































Multicast Transmission from One Transmitter to Three Local Receivers 
50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(M^abits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

1900 

0.216 



128 

1103 

0.371 

400 

2.757 

256 

665 

0.616 

200 

3.325 

512 

525 

0.780 

100 

5.250 

1024 

441 

0.929 

50 

8.820 

2048 

401 

1.021 

25 

16.040 

4096 

332 

1.234 

13 

25.538 

8192 

^24 

1.264 

7 

46.286 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

1828 

0.224 

800 

2.285 

128 

1091 

0.375 

400 

2.728 

256 

690 

0.594 

200 

3.450 

512 

586 

0.699 

100 

5.860 

1024 

387 

1.058 

50 

7.740 

2048 

359 

1.141 

25 

14.360 

4096 

347 

1.180 

13 

26.692 

8192 

370 

1.107 

7 

52.857 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2637 

0.155 

800 

3.296 

128 

1092 

0.375 

400 

2.730 

256 

774 

0.529 

200 

3.870 

512 

483 

0.848 

100 

4.830 

1024 

381 

1.075 

50 

7.620 

2048 

359 

1.141 

25 

14.360 

4096 

333 

1.230 

13 

25.615 

8192 

324 

1.264 

7 

46.286 


91 
























































































































Multicast Transmission from One Transmitter to Three Local Receivers 
with Induced Errors (1 of 25 Packets) 

50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2923 

0.140 

800 

3.654 

128 

1305 

0.314 

400 

3.263 

256 

855 

0.479 

200 

4.275 

512 

759 

0.540 

100 

7.590 

1024 

411 

0.997 

50 

8.220 

2048 

497 

0.824 

25 

19.880 

4096 

346 

1.184 

13 

26.615 

8192 

394 

1.040 

7 

56.286 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

2346 

0.175 

800 

2.933 

128 

1309 

0313 

400 

3.272 

256 

1173 

0.349 

200 

5.865 

512 

718 

0.570 

100 

7.180 

1024 

506 

0.809 

50 

10.120 

2048 

455 

0.900 

25 

18.200 

4096 

340 

1.205 

13 

26.154 

8192 

584 

0.701 

7 

83.429 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 


Number of 
calls 

Latency 
(milliseconds 
i)er call) 

64 

2148 

0.191 

800 

2.685 

128 

1244 

0.329 

EEOHHHIif 

3.110 

256 

1084 

0.378 


5.420 

512 

584 

0.701 

100 

5.840 

1024 

452 

0.906 

50 

9.040 

2048 

500 

0.819 

25 

20.000 

4096 

438 

0.935 

13 

33.692 

8192 

422 

0.971 

7 

60.286 


92 

























































































































Multicast Transmission from One Transmitter to Three Local Receivers 
with Induced Errors (1 of 10 Packets) 

50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3128 

0.131 

800 

3.910 

128 

1788 

0.229 

400 

4.470 

256 

1200 

0.341 

200 

6.000 

512 

741 

0.553 

100 

7.410 

1024 

623 

0.657 

50 

12.460 

2048 

775 

0.529 

25 

31.000 

4096 

456 

0.898 

13 

35.077 

8192 

718 

0.570 

7 

102.571 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

64 

3111 

128 

1737 

256 

976 

512 

677 

1024 

589 

2048 

636 

4096 

441 

8192 

851 


Run 3 


Throughput 
(Megabits per 
second) 


Number of 
calls 




3.889 


4.343 


4.880 


6.770 


11.780 


25.440 


33.923 


121.571 




93 





















































































































Multicast Transmission from One Transmitter to Three Local Receivers 
with Induced Errors (1 of 5 Packets) 

50K Message Size (51200 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3327 

0.123 

800 

4.159 

128 

1796 

0.228 

400 

4.490 

256 

1026 

0.399 

200 

5.130 

512 

681 

0.601 

100 

6.810 

1024 

^7 

0.698 

50 

11.740 

2048 

603 

0.679 

25 

24.120 

4096 





8192 






Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3193 

0.128 

800 

3.991 

128 

1890 

0.217 

400 

4.725 

256 

1014 

0.404 

200 

5.070 

512 

751 

0.545 

100 

7.510 

1024 

558 

0.734 

50 

11.160 

2048 





4096 





8192 






Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

3192 

0.128 

800 

3.990 

128 

2009 

0.204 

400 

5.022 

256 

1314 

0.312 

200 

6.570 

512 

907 

0.452 

100 

9.070 

1024 

567 

0.722 

50 

11.340 

2048 





4096 





8192 




























































































Unicast Transmission from One Transmitter to One Local Receiver 
with No Induced Errors 
1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

76082 

0.108 

16000 

4.755 

128 

38912 

0.211 

8000 

4.864 

256 

18658 

0.439 

4000 

4.665 

512 

9779 

0.838 

2000 

4.889 

1024 

5487 

1.493 

1000 

5.487 

2048 

3486 

2.350 

500 

6.972 

4096 

2345 

3.493 

250 

9.380 

8192 

2300 

3.562 

125 

18.400 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

76715 

0.107 

16000 

4.795 

128 

37733 

0.217 

8000 

4.717 

256 

18918 

0.433 

4000 

4.729 

512 

9594 

0.854 

2000 

4.797 

1024 

5446 

1.504 

1000 

5.446 

2048 

4248 

1.928 

500 

8.496 

4096 

2121 

3.862 

250 

8.484 

8192 

2180 

3.758 

125 

17.440 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(mUliseconds 
per call) 

64 

74346 

0.110 

16000 

4.647 

128 

37105 

0.221 

8000 

4.638 

256 

18871 

0.434 

4000 

4.718 

512 

9532 

0.859 

2000 

4.766 

1024 

5448 

1.504 

1000 

5.448 

2048 

3519 

2.328 

500 

7.038 

4096 

2319 

3.533 

250 

9.276 

8192 

12523 

3.247 

125 

20.184 
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Unicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 25 Packets) 

1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

51021 

0.161 

16000 

3.189 

128 

28869 

0.284 

8000 

3.609 

256 

14050 

0.583 

4000 

3.513 

512 

7409 

1.106 

2000 

3.704 

1024 

4094 

^001 

1000 

4.094 

2048 

2555 

3.206 

500 

5.110 

4096 

2498 

3.279 

250 

9.992 

8192 

2200 

3.724 

125 

17.600 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

51187 

0.160 

16000 

3.199 

128 

27790 

0.295 

8000 

3.474 

256 

14694 

0.558 

4000 

3.674 

512 

7312 

1.120 

2000 

3.656 

1024 

3972 

2.062 

1000 

3.972 

2048 

2600 

3.151 

500 

5.200 

4096 

2629 

3.116 

250 

10.516 

8192 

2170 

^.775 

125 

17.360 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

50749 

0.161 

16000 

3.172 

128 

28534 

0.287 

8000 

3.567 

256 

14274 

0.574 

4000 

3.568 

512 

7299 

1.122 

2000 

3.650 

1024 

4071 


EOSIiBHHil 

4.071 

2048 

2621 

3.126 


5.242 

4096 

1917 

4.273 

250 

7.668 

8192 

2465 

3.323 

125 

19.720 
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Unicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 10 Packets) 

1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

80595 

0.102 

16000 

5.037 

128 

34795 

0.235 

8000 

4.349 

256 

18977 

0.432 

4000 

4.744 

512 

9963 

0.822 

2000 

4.981 

1024 

5618 

1.458 

1000 

5.618 

2048 

5068 

1.616 

500 

10.136 

4096 

4282 

1.913 

250 

17.128 

8192 

4282 

1.913 

125 

34.256 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

73550 

0.111 

16000 

4.597 

128 

39202 

0.209 

8000 

4.900 

256 

19526 

0.420 

4000 

4.881 

512 

10426 

0.786 

2000 

5.213 

1024 

5907 

1.387 

1000 

5.907 

2048 

4089 

2.003 

1500 

8.178 

4096 

3987 

2.055 

250 

15.948 

8192 

9783 

0.837 

125 

78.264 


Run 3 


Buffer Size 
(Bytes) 

np* • 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

74717 

0.110 

16000 

4.670 

128 

36851 

0.222 

8000 


256 

18843 

0.435 

4000 

4.711 

512 


0.818 

2000 

5.008 

1024 

5763 

1.421 

IliHilHIlHH 

5.763 

2048 

3982 

2.057 


7.964 

4096 

2597 

3.154 

250 

10.388 

8192 

5153 

1.590 

125 

41.224 
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Unicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 5 Packets) 

1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

72083 

0.114 

16000 

4.^5 

128 

36554 

0.224 

8000 

4.569 

256 

19927 

0.411 

4000 

4.982 

512 

10476 

0.782 

2000 

5.238 

1024 

6329 

1.294 

1000 

6.329 

2048 

9938 

6.824 

500 

19.876 

4096 

30313 

0.270 

250 

121.252 

8192 

20814 

0.394 

125 

166.512 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

80292 

0.102 

16000 

5.018 

128 

37261 

0.220 

8000 

4.658 

256 

19194 

0.427 

4000 

4.798 

512 

10670 

0.768 

2000 

5.335 

1024 

6149 

1.332 

1000 

6.149 

2048 

8089 

1.013 

500 

16.178 

4096 

29177 

0.281 

250 

116.708 

8192 

21598 

0.379 

125 

172.784 


Run 3 


Buffer Size 
(Bytes) 

np* • 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

77446 

0.106 

16000 

4.840 

128 

36824 

0.222 


4.603 

256 

19402 

0.422 

4000 

4.851 

512 

10561 

0.776 

2000 

5.280 

1024 

5985 

1.369 

1000 

5.985 

2048 

7247 

1.130 

500 

14.494 

4096 

32681 

0.251 

250 

130.724 

8192 

9644 

0.849 

125 

7^152 
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Multicast Transmission from One Transmitter to One Local Receiver 
1 Meg Message Size (1024000 bytes) 


Run 1 


BulTer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

78467 

0.104 

16000 

4.904 

128 

37261 

0.220 

8000 

4.658 

256 

19132 

0.428 

4000 

4.783 

512 

9360 

0.875 

2000 

4.680 

1024 

5554 

1.475 

1000 

5.554 

2048 

4122 

1.987 

500 

8.244 

4096 

2188 

3.744 

250 

8.752 

8192 

1580 

5.185 

125 

12.640 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

78622 

0.104 

16000 

4.914 

128 

39548 

0.207 

8000 

4.944 

256 

19767 

0.414 

4000 

4.942 

512 

9332 

0.878 

2000 

4.666 

1024 

5573 

1.470 

1000 

5.573 

2048 

3591 

2.281 

500 

7.182 

4096 

2200 

3.724 

250 

8.800 

8192 

1617 

5.066 

^5 

12.936 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

78446 

0.104 

16000 

4.903 

128 

37612 

0.218 

8000 

4.702 

256 

20031 

0409 

4000 

5.008 

512 

9127 

0.898 

2000 

4.564 

1024 

5383 

1.522 

1000 

5.383 

2048 

3557 

2.303 

500 

7.114 

4096 

2202 

3.720 

250 

8.808 

8192 

1631 

5.023 

125 

13.048 
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Multicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 25 Packets) 

1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

68101 

0.120 

16000 

4.256 

128 

26100 

0.314 

8000 

3.263 

256 

13129 

0.624 

CniSBHHiH 

3.282 

512 

6951 

1.179 

EUHBIHIHI 

3.475 

1024 

4861 

1.685 

1000 

4.861 

2048 

5407 

1.515 

500 

10.814 

4096 

3755 

2.182 

250 

15.020 

8192 

2658 

3.082 

125 

21.264 


Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

70388 

0.116 

16000 

4.399 

128 

25493 

0321 

8000 

3.187 

256 

13371 

0.613 

4000 

3.343 

512 

7017 

1.167 

2000 

3.509 

1024 

5398 

1.518 

1000 

r5.398 

2048 





4096 

3841 

2.133 

250 

15.364 

8192 

3789 

2.162 

125 

30.312 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

69370 

0.118 

16000 

4.336 

128 

26108 

0.314 

8000 

3.264 

256 

13789 

0.594 

4000 

3.447 

512 

7095 

1.155 

2000 

3.547 

1024 

4704 

1.741 

1000 

4.704 

2048 





4096 

3890 

2.106 

250 

15.560 

8192 




















































































Multicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 10 Packets) 

1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

243436 

0.034 

16000 

15.215 

128 

119628 

0.068 

8000 

14.954 

256 

24038 

0.341 

4000 

6.010 

512 

12599 


2000 

6.300 

1024 

10162 

0.806 

1000 

10.162 

2048 

^06 

1.387 

500 

11.812 

4096 

5590 

1.465 

250 

22.360 

8192 

3857 

2.124 

125 

30.856 


Run 2 


Buffer Size 
(Bytes) 

nn* • 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

247312 

0.033 

16000 

15.457 

128 

118551 

0.069 

8000 

14.819 

256 

29629 

0.276 

4000 

7.407 

512 

12298 

0.666 

2000 

6.149 

1024 

6914 

1.185 

1000 

6.914 

2048 

5529 

\1AS2 

500 

11.058 

4096 

5334 

1.536 

^0 

21.336 

8192 






Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

—---- 


Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

259057 

0.032 

16000 

16.191 

128 

92649 

0.088 

8000 

11.581 

256 

22558 

0.363 

4000 

5.639 

512 

12519 

0.654 

2000 

6.260 

1024 

7780 

1.053 

1000 

7.780 

2048 

4982 

i.644 

500 

9.964 

4096 

5142 

1.593 

^0 

20.568 

8192 
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Multicast Transmission from One Transmitter to One Local Receiver 
with Induced Errors (1 of 5 Packets) 

1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

rwi* • 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

80825 

0.101 

16000 

5.052 

128 

46106 

0.178 

8000 

5.763 

256 

24424 

0.335 

4000 

6.106 

512 

13842 

0.592 

2000 

6.921 

1024 

7332 

1.117 

1000 

7.332 

2048 

7261 

1.128 

500 

14.522 

4096 

6750 

1.214 

250 

27.000 

8192 






Run 2 


Buffer Size 
(Bytes) 

rwi* • 

Timing 

(milliseconds) 



Latency 
(milliseconds 
per call) 

64 

74872 

0.109 

16000 

4.679 

128 

37821 

0.217 

8000 

4.728 

256 

20415 

0.401 

4000 

5.104 

512 

12316 

0.665 

2000 

6.158 

1024 

8629 

0.949 

1000 

8.629 

2048 

6991 

1.172 

500 

13.982 

4096 

6275 


250 

25.100 

8192 






Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

73208 

0.112 

16000 

4.575 

128 

43797 

0.187 

8000 

5.475 

256 

21533 

0.380 

4000 

5.383 

512 

12127 

0.676 

2000 

6.064 

1024 

7362 


1000 

7.362 

2048 

5979 

1.370 

500 

11.958 

4096 





8192 
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Multicast Transmission from One Transmitter to Two Local Receivers 
1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

75383 

0.109 

16000 

4.711 

128 

37114 

0.221 

8000 

4.639 

256 

17976 

0.456 

4000 

4.494 

512 

9495 

0.863 

2000 

4.747 

1024 

5569 

1.471 

1000 

5.569 

2048 

3589 

2.283 

500 

7.178 

4096 

2210 

^707 

[250 

8.840 

8192 

1603 

5.110 

125 

12.824 


Run 2 


Buffer Size 
(Bytes) 

rin^ • 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

78702 

0.104 

16000 

4.919 

128 

40246 

0.204 

8000 

5.031 

256 

17802 

0.460 

4000 

4.450 

512 

9211 

0.889 

2000 

4.606 

1024 

5645 

1.451 

1000 

5.645 

2048 

3561 

2.300 

500 

7.122 

4096 

2166 

3.782 

250 

8.664 

8192 

1571 

5.215 

125 

12.568 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 


Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

79621 

OESIHBH 

16000 

4.976 

128 

40061 

0.204 

8000 

5.008 

256 

19278 

0.425 

4000 

4.819 

512 

9035 

0.907 

2000 

4.518 

1024 

5515 

1.485 

1000 

5.515 

2048 

3561 

2.300 

500 

7.122 

4096 

2249 

3.643 

250 

8.996 

8192 

1544 

5.306 

125 

12J52 
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Multicast Transmission from One Transmitter to Two Local Receivers 
with Induced Errors (1 of 25 Packets) 

1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

107597 

0.076 

16000 

6.725 

128 

66854 

0.123 

8000 

8.357 

256 

22289 

0.368 

4000 

5.572 

512 

13767 

0.595 

2000 

6.883 

1024 

7111 

1.152 

1000 

7.111 

2048 

4019 

2.038 

500 

8.038 

4096 





8192 






Run 2 


Buffer Size 
(Bytes) 


Timing 

(milliseconds) 



put 
s per 


Number of 
calls 


16000 


8000 


4000 


2000 


1000 


500 




5.907 


5.486 


5.895 


6.444 


8.814 


9.758 


Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

78175 

0.105 

16000 

4.886 


37069 

0.221 

8000 

4.634 


18928 

0.433 

4000 

4.732 

512 

10386 

0.789 

2000 

5.193 

1024 

7230 

1.133 

1000 

7.238 



























































































Multicast Transmission from One Transmitter to Two Local Receivers 
with Induced Errors (1 of 10 Packets) 

1 Meg Message Size (1024000 bytes) 


Ron 1 


Buffer Size 
(Bytes) 

nn« • 

Timing 

(milliseconds) 


Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

166857 

0.049 

16000 

10.429 

128 

75445 

0.109 

8000 

9.431 

256 


0.267 

4000 

7.673 

512 

11023 

0.743 

2000 

5.511 

1024 

6597 

1.242 

1000 

6.597 

2048 

6218 

ri.317 

500 

12.436 

4096 

4872 

1.681 

250 

19.488 

8192 

4418 

1.854 

125 

35.344 


Run 2 


Buffer Size 
(Bytes) 



Timing 

(milliseconds) 


142547 


48417 


29636 


10887 


Throughput 
(Megabits per 
second) 



.169 


0.276 


0.752 


1.241 


1.305 


2.146 


1.642 


Number of 
calls 


16000 


8000 


4000 


2000 


1000 


500 



8.909 


6.052 


7.409 


5.444 


6.601 


12.552 


15.272 


39.904 
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Multicast Transmission from One Transmitter to Two Local Receivers 
with Induced Errors (1 of 5 Packets) 

1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

110177 

0.074 

16000 

6.886 

128 

44582 

0.184 

8000 

5.573 

256 

40007 

0.205 

4000 

10.002 

512 

11290 

0.726 

2000 

5.645 

1024 

7324 

1.119 

1000 

7.324 

2048 

6848 

1.196 

500 

13.696 

4096 





8192 






Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

185618 

0.044 

16000 

11.601 

128 

60400 

0.136 

8000 

7.550 

256 

21411 

0.383 

4000 

5.343 

512 

11971 

0.684 

2000 

5.986 

1024 

12038 

0.681 

1000 

12.038 

2048 

17847 

0.459 

500 

35.694 

4096 





8192 






Run 3 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 


Latency 
(milliseconds 
per call) 

64 

209749 

0.039 

16000 

13.109 

128 

58771 

0.139 

8000 

7.346 

256 

22424 

0.365 

4000 

5.606 

512 

11408 

0.718 

2000 

5.704 

1024 

7908 

1.036 

1000 

7.908 

2048 

6531 

1.254 

500 

13.062 

4096 





8192 








































































































Multicast Transmission from One Transmitter to Three Local Receivers 
1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

80010 

0.102 

16000 

5.001 

128 

40375 

0.203 

8000 

5.047 

256 

17018 

0.481 

4000 

4.255 

512 

9229 

0.888 

2000 

4.614 

1024 

5577 

1.469 

1000 

5.577 

2048 

3610 

2.269 

500 

7.220 

4096 

2^3 

3.669 

250 

8.932 

8192 

1646 

4.977 

125 

13.168 


Run 2 



Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

64 

79856 

128 

36210 

256 

20407 

512 

9342 

1024 

5612 

2048 

3605 

4096 

2325 

8192 

1592 



0.103 


.226 


.401 


.877 


1.460 


2.272 


3.523 


5.146 


16000 



4.991 


4.526 


5.102 


4.671 


5.612 


7.210 


9.300 


12.736 



Buffer Size 
(Bytes) 

Timing 

(milliseconds) 


Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

74049 

0.111 

16000 

4.628 

128 

40261 

0.203 

8000 

5.033 

256 

18122 

0.452 

4000 

4.530 

512 

9129 

0.897 

2000 

4.564 

1024 

5530 

1.481 

1000 

5.530 

2048 

3655 

2.241 

500 

7.310 

4096 

r2184 

3.751 

250 

8.736 

8192 

1689 

4.850 

125 

13.512 
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Multicast Transmission from One Transmitter to Three Local Receivers 
with Induced Errors (1 of 25 Packets) 

1 Meg Message Size (1024000 bytes) 


Run 1 


Bufier Size 
(Bytes) 


64 

128 

256 

512 

1024 

2048 

4006 

8192 


Timing 

(milliseconds) 


93761 

44393 

18814 

12976 

8748 

4014 


Throughput 
(Megabits per 

second) _ 

0.087 _ 

0.185 _ 

0.435 _ 

0.631 _ 

0.936 _ 

2.041 


Number of 
calls 


16000 

8000 

4000 

2000 

1000 

500 


Laten 

(minis 

per ca 

5.860 

5.549 

4.704 

6.488 

8.748 

8.028 


Run 2 


Buffer Size 
(Bytes) 


64 

128 

256 

512 

1024 

2048 

4096 

8192 


Timing 

(milliseconds) 


72553 

37762 

19319 

14117 

8890 

4124 


Throughput 
(Megabits per 

second) _ 

0.113 _ 

0.217 _ 

0.424 _ 

0.580 _ 

0.921 _ 

1.986 


Number of 
calls 


16000 

8000 

4000 

2000 

1000 

500 


Latenr 

(minis 


per ca 

4.535 

4.720 

4.830 

7.059 

8.890 

8.248 


Run 3 


Buffer Size 
(Bytes) 


64 

128 

256 

512 

1024 


Timing 

(milliseconds) 


82543 

37336 

20611 

10317 

5923 


Throughput 
(Megabits per 

second) _ 

0.099 _ 

0.219 _ 

0.397 _ 

0.794 _ 

1.383 


Number of 
calls 


16000 

8000 

4000 

2000 

1000 


Latenr 

(minis* 


per cal 

5.159 

4.667 

5.153 

5.159 

5.923 




























































































Multicast Transmission from One Transmitter to Three Local Receivers 
with Induced Errors (1 of 10 Packets) 

1 Meg Message Size (1024000 bytes) 



Run 1 


Buffer Size 
(Bytes) 


Timing 

(milliseconds) 



.067 


0.167 


.275 


0.772 


1.297 



Number of 
calls 


16000 


8000 


4000 


2000 


1000 



7.692 


6.118 


7.449 


5.308 


6.315 


Run 2 


Buffer Size 
(Bytes) 


64 


128 


256 


512 


1024 


2048 


4096 


8192 



Timing 

(milliseconds) 


82547 


48873 


20208 


11728 


6453 


Number of 
calls 


16000 


8000 


4000 


2000 


1000 



5.159 


6.109 


5.052 


5.864 


6.453 



Run 3 


Buffer Size 
(Bytes) 


64 


128 


256 


512 


1024 


2048 


4096 


8192 


Timing 

(milliseconds) 


85261 


38756 


19694 


12397 


7684 



li 


.096 


0.211 


0.416 


.661 


1.066 


Number of 
calls 


16000 


8000 


4000 


2000 


1000 



5.329 


4.845 


4.923 


6.199 


7.684 















































































Multicast Transmission from One Transmitter to Three Local Receivers 
with Induced Errors (1 of 5 Packets) 

1 Meg Message Size (1024000 bytes) 


Run 1 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

ik|| 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

124130 

0.066 

16000 

7.758 

128 

39966 

0.205 

8000 

4.996 

256 

24437 

0.335 

4000 

6.m 

512 

12400 

0.661 

2000 

6.200 

1024 

7978 

1.027 

1000 

7.978 

2048 





4096 





8192 






Run 2 


Buffer Size 
(Bytes) 

Timing 

(milliseconds) 

Throughput 
(Megabits per 
second) 

Number of 
calls 

Latency 
(milliseconds 
per call) 

64 

94894 

0.086 

16000 

5.931 

128 

39780 

0.206 

8000 

4.973 

256 

26229 

0.312 

4000 

6.557 

512 

10891 

0.752 

2000 

5.446 

1024 

6945 

1.180 

1000 

6.945 

2048 





4096 





8192 


i_ 





Run 3 


Buffer Size 
(Bytes) 


Timing 

(milliseconds) 



Throughput 
(Megabits per 
second) 

Number of 
calls 

0.103 

16000 

0.205 

8000 

0.398 

4000 

0.639 

2000 

0.891 

1000 
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